(my friend Tom is cc:'d as the Multics expert, re: the ref below) -----BEGIN PGP SIGNED MESSAGE-----
Date: Mon, 2 Oct 1995 17:13:21 -0700 (PDT) From: Simon Spero <ses@tipper.oit.unc.edu>
Lets use 3DES as our example. We'll start with a naive specification:
[etc.] You're starting down the same road I did in writing my example of how ASN.1 seduces you into bad design. ..very good, but you stopped short. [The PER sounds much better than BER -- but I've never seen PER before. I learned enough about ASN.1 to have decided it is a lost cause -- far easier to let ASN.1 advocates talk to themselves while I go off to do something independent and good.] Back to the example.
-- LongLong ::= OCTET STRING (SIZE(8)) -- a long long is 8 bytes, er, long
Really? There is an OCTET STRING (SIZE(8)) and you can make it a datatype? I suppose you can make an OCTET STRING (SIZE(9)) too? That can be really convenient. You can have a tagged quantity (using the top byte). Alternatively, someone could define: DesKey ::= SEQUENCE { encr BIT STRING (SIZE(1)), -- encrypt mode if 1, decrypt if 0 value OCTET STRING (SIZE(8)) } and now you can use DesKey as your data type with no bad effects and only good ones (as far as the ASN.1 user is concerned). Of course, the code to pack/unpack just exploded. So did the packet size (maybe, depending on effort spent in pack/unpack) and so did the internal struct, probably. [Truth in advertising: the example above is adapted from early Multics where PL/I allowed you to do such nonsense and some programmer saw the power of it -- so he used it in the file system, until he got caught.] Lesson from this: there is a reason not to give a designer generality you would not use in an actual implementation. Anyway -- my example of ASN.1 abuse is along these lines but I won't reproduce it here. We can leave this as a parlor game for computer geeks. :-)
Here's the new definitions:
-- Long ::= OCTET STRING (SIZE(4))
ThreeDes ::=SEQUENCE { IV SEQUENCE OF (SIZE(1..2) LONG, Key1 DesKey, Key2 DesKey OPTIONAL, Key3 DesKey OPTIONAL }
See -- ASN.1 is powerful in its seductiveness. Even though you were trying to convince me that it can be the same as my primitive example (and therefore just as efficient), you couldn't resist using the power of the generality to elaborate on the structure. This is not a good feature of ASN.1. This is its primary fault. This is why I call it a work of Satan. (BER/DER helps in that evaluation, of course).
To be continued... (unless I get flamed off the list)
As I said, this could be a wonderful parlor game -- or list topic, if people want to waste the time. Think of it as the Crossword Puzzle page of the cypherpunks on-line newspaper. :-) - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme@tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHFNJFQXJENzYr45AQFV2AP9H1/A5bY4H8C/Ms3dhHIPOWiLCYhqLzFR qKdvQaBYvPDCrr8jXLwQhTogvzu/9gkZ2DwnXVya7MxEpyy+1A5WrO3Jlqu+6Euy bBcl1idhoomMzmzOga/F7YasXsFkoZoSqNYQKX/ZKcFvEuDGrzohlBNV5ubDEL7G E3hdsak0f2Y= =cjU/ -----END PGP SIGNATURE-----