December 2003 - cypherpunks-legacy

No Subject
by Eric.K.Kuecherer＠Dartmouth.EDU 17 Dec '03

17 Dec '03

Please remove me from the list. -kuech-

1 0

Re: a horrible conspiracy revealed!
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

> I wonder what the significance of L. Detweiler's name is? Obviously > its a Germanic name. Perhaps he's a Nazi... in fact, he might be the Graham> I sincerely *hope* this article was a forgery, Graham> otherwise Perry you're digging yourself a big Graham> credibility hole. Drop it, please. I guess you didn't get it huh? I'm really sick of the flame wars on here, but this one had me laughing on the floor. No, I did get the joke, I just didn't think it was funny. I *do* remember the thread some time ago of Perry being accused of being a Nazi because a well- known Illinois Nazi has the same surname. I meant he was losing credibility for indulging in childish games, not for meaning whatever he said literally. I'd rather the pair of them just let it drop, instead of trying to outsmart each other. G

3 2

META: Re: a horrible conspiracy revealed!
by jrk＠sys.uea.ac.uk 17 Dec '03

17 Dec '03

I was about to do an ::exclude on this thread, when I realised that it was the cypherpunks list and not the extropians. Any chance of cypherpunks running the extropian list software? Or maybe it does already? -- ____ Richard Kennaway __\_ / School of Information Systems Internet: jrk(a)sys.uea.ac.uk \ X/ University of East Anglia uucp: ...mcsun!ukc!uea-sys!jrk \/ Norwich NR4 7TJ, U.K

3 2

Re: Clipper specifics (more)
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>From MIKEINGLE(a)delphi.com Wed Sep 29 20:44:02 1993 >Where do you get the MYK spec? From: Mykotronx, Inc. 357 Van Ness Way, Suite 200 Torrance, CA 90501 (310) 533-8100 FAX (310) 533-0527 The cover title is "VLSI Encryption/Decryption Device Data" The title block on the first page is "MYK-78 Encryption/Decryption Device" There is no copyright notice, I'm a bit vague on whether such notice is required at present. Each page bears the trademark of Mykotronx. >Do Type 1 chips use 80-bit keys like Clipper? One of the characteristics of data sheets for type I chips incommon with the MYK-78, is that no where are byte counts mentioned. The specs instead refer to reading or writing requisite bytes to satisfy testable flags. Even examining key storage device specs (Crypto Ignition Key, etc.) no byte counts are mentioned, rather a count value is specified in the header structure. One could assume that the key size of a type I device is classified. Some with exposure to Type I implementations believe that independent round keys are loaded, requiring a lot more storage. Having seen references to the cryptographic check word in Type I specs, I don't. Type I chip Cryptographic Algorithms (CA) are not specified in theire unclassified spec sheets and are presumeably classified. It is my personal belief that the cryptographic algorithm (SKIPJACK) may be the same as used in Type I devices. Major differences other than ambiguity with respect to the cryptographic algorithm, between Clipper and Type I devices includes: 1) No Red/Black Separation the MYK-78 has a single data port 2) The MYK-78 allows you to "fish" for the Cryptographic Check Word (CCW), a value used to verify the key has been loaded correctly. Type I devices require the CCW be correct, otherwise requiring passing through reset. This implies a central key management authority. 3) Strict certification requirements for Type I implementations, similar to that done for devices/firmware/software used for controling and releasing nuclear weapons. One presumes the level of testing for Escrow Encryption Standard compliant devices will be done to the black box level if conducted by NIST. 4) Some Type I chips include two sets of Cryptographic Algorithm hardware for FULL DUPLEX operatiion in a communications environment. There are otherwise higher levels of integration as well. 5) Type I chips generally contain provision for remote rekeying and remote zeroizing. Presumeably these same facilities are instead dedicated to the Law Enforcement Exploitation Field in the MYK-78. 6) At least one Type I chip is a hybrid, also cotaining an Intel 8051 type microprocessor. It is possible that the same silicon is used for clipper and Type I devices, were two different I/O pads (red and black ports) located adjacent but interleaved, with the same package pin bonded to both pads. Enabling CCW fishing could be a bonding option. While one could argue that red/black area partitioning might be employed on the silicon it is worth remembering that during encryption, only the final product is black, and for decryption the final product is red. The flexibility in control programming mentioned for the MYK-78 could reflect the requisite ability to control red and black ports as well as using remote rekeying/remote zeroizing facilities for LEEF. >How far ahead of such cyphers as IDEA and 3DES are the Type 1 cyphers? >Much more secure, or are we pretty close to *them*? Judging from the clipper chip, not much. The number of clocks for executing the CA in a Type I chip is the same as the clipper chip (64 clocks). The MYK-78 has been publicly stated to perform 32 rounds (one could image 64 rounds in 64 clocks). #From: wcs(a)anchor.ho.att.com (Bill Stewart +1-908-949-0705) ... #There's a little more information than that, though not much. #The Mykotronix blurb says that the algorithm uses S-boxes, and takes #64 clocks to do the encryption; I think someone said it's 32 rounds of >S-boxes, which would correspond well with this. ... #My personal speculation is that it's probably about 24-key-bits #stronger than DES, but I don't have a good guess on the weak keys issue. In Dorthy Dennings preliminary report on Skipjack there were several points of interest brought up in the overview on the cryptographic algorithm: 1) Differential Cryptanalysis ...We concluded it was not + possible to perform an attack based on differential cryptanalysis in + less time than with exhaustive search. -- Increasing the number of rounds descreases the S/N ratio. Changing The XOR for mixing key and data iin the cryptographic function f(R,K) to an adder would likewise make exhaustive search faster than differential cryptanalysis for DES (Chapter 4 of E. Biham and A. Shamir "Differential Cryptanalysis of the DES Encryption Algorithm", 1993 Springer-Verlag.) 2) Weak Keys + ... We saw no pattern of symmetry in the + SKIPJACK algorithm which could lead to weak keys. -- A key is weak when the encryption function and decryption function are identical (the same key works for either) 3) Symmetry Under Complementation + ...We tested SKIPJACK for this property and found + that it did not hold. -- In DES K XOR E(R) == !K XOR E(!R). All three of these can be defeated by exchanging the XOR between key and data in f(R,K) with adders. The carry is a good place to introduce more key bits per round (8 bits when modulo 64). Subtraction is used for decryption and addition for encryption (or vice versa). The key schedule is relatively easy to extend to 80 bits from 56. It might not be this easy, but then again it could. DES also has a property of the S boxes that collectively map a 32 bit input value (R) to a 32 bit output value (SboxP) according to a 48 bit subkey (Kn) that for a large portion of the keys, there are not 2^32 distinct output values. Where the holes occur in the output domain are dependent on the key, and key and not key have the same holes. Exploring this property has led investigators to discover differential cryptanalysis and linear cryptanalysis. If it were possible to "see" the output of the P permutation directly you could discover the round key (Kn) over a large amount of chiphertext by simply checking for 32 bit symbols that don't show up. Correlating missing symbols to keys is a momentous task, potentially requiring years. It is possible that a 4th category of cryptanalysis attack (Brute force is the other method) is predicated on this property (D.W. Davies cryptically :) mentions a method of discovering 16 key bits in his book published in the U.S. in 1983, I believe). Skipjack may have provision for defeating this hypothetical attack.

1 0

PGP in FIDO
by anonymous＠extropia.wimsey.com 17 Dec '03

17 Dec '03

* Reply to msg originally in CYPHERPUNKS > My question is this: how does he know that the mail is encrypted if he's > not examining the mail that passes through his system? If he *is* > examining the mail that passes through his system, it seems likely that he > is violating the Electronic Communications Privacy Act. In that FIDOnet mail points (or individual BBSs) are not required to pass or accept encrypted FIDO traffic under FIDOnet rules, some run a specific program that scans for the "PGP MESSAGE" string and bumps it to a SECURENET mail hub (or, in some cases, _kills_ it). It is not done by individual, personal inspection - at least not at mail hub level. Anyway, the ECPA is basically irrelevant in the BBS world, as 1] almost every BBS states at log-on that there is no such thing as truly "private" e-mail on the system as the sysop can, will and does see messages in all areas, and 2] he is personally _liable_ for any illegal activity on his BBS, so he can reasonably be expected to keep an eye on e-mail for anything that will put his ass in a sling. There has been a very heated war in FIDOland over PGP and other encryption. Considering the risk that sysops take on by permitting secure (?) communication on their BBSs, I must say I admire their courage when they allow it and participate on SECURENET. Personally, _I_ would never stick my neck out like that, though I convinced many FIDOnet BBSs to do so for my own political and purely selfish reasons. BTW, this message comes via FIDOnet and was originally PGP encrypted for the remailer, and the cypherpunks(a)toad.com mailing is converted to a conference on a FIDO BBS where I read the message to which I am responding.

10 25

POISON PILL
by Matthew J Miszewski 17 Dec '03

17 Dec '03

Sandy, There are a number of ways in which you can set up *your* machine to self-destruct. The best way to accomplish this is through Perry's suggestion of a regular security check to which you must reply or the PILL is activated. If all you are concerned about is private mail or the like, a simple batch wipe file would work (hide the wipe program). Putting any prompt at boot and turning off obvious ways of defeating *your* security will help. Not to start everyone flaming, but there is nothing wrong with destroying your own computer thru infamous combinations of interrupt hooks and the like (was that cryptic enough to avoid a virii flame?) --Matt ______________________________________________________________________________ "This new technology (the printing press) threatened the Crown, which shuddered at the thought of widespread dissemination of works advocating religious heresy and political upheaval. The Crown's solution to the problem was a system of regulation designed to control this "dangerous" art." -From my Copyright Law Text (refrencing the Statute of Anne - the first Copyright Statute) (c)1993 ______________________/___________________________________mjmiski(a)macc.wisc.edu

1 0

REMAIL: digicash
by nobody＠rosebud.ee.uh.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, I've been experimenting with a primitive digital cash system for remailers. Originally I had hoped to combine the remailing and banking functions of the elee7h5@rosebud remailer, but for now I have an even more primitive cash system implemented at elee6ue@rosebud. It seems to be performing as expected. A digital cash accepting remailer, along with a good positive reputation system, is the "crypto-anarchist" answer to labeling anonymous mail with subjects and/or usernames. (Of course, a subject that enables anonymous mail to blend in is great - such as "Re: your mail"). (Incidentally, since running pgp to get the signature from a pgp-signed message is expensive, I patched the script I use for positive reputation to give the option of checking signatures or not, if anybody is interested.) Currently, the only objection I've heard to anonymous mail is "somebody can abuse it"; future remailers will require payments, helping to address this concern. Basically, the remailer recognizes a Digicash pasting token, and for now the cash is a string of letters and numbers. Before remailing, the digicash is extracted and looked up in a cash list (which I create). If the cash is in the list, it is assumed to be valid, and the list is rewritten minus the cash string just used. If the cash isn't present, it is assumed to be invalid, and an insufficient funds message is remailed instead. The remailer does not keep a list of "spent" cash strings, so there is the possibility of duplication (once in every 36^60 times). As far as correlating the cash used to individual and a message, I can only assure you I could care less about the required bookkeeping. The pasting token looks like the others, and you use it in a similar way - - ----------8< cut here >8---------- :: Digicash: <here is the string> - ----------8< cut here >8---------- For example, I "paid" for the remailing of this message with - ----------8< cut here >8---------- :: Digicash: BcKjSoUEQaTam9xPs0oso2j0UVVb1M6OyxTn8QSX0rdT3eUIH4Vq1rXEpYH1D - ----------8< cut here >8---------- (Now, the above cash string should be invalid! :-) The way I'm distributing valid cash for the remailer is by email - mail me and I'll send you some valid cash strings. No charge :-) Karl L. Barrus <klbarrus(a)owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLKsyGYOA7OpLWtYzAQG/QAQAwNbDbKOdnWJ4g/tt8+0AdtR+5TzETfaU DaodN1LDs7+w46/KlyIoI/B9+C710U1f46dnd81MxMm6eTGcbwnkrTBhz7QlO7NH 1joVaoe8TVljk2RZnCYmpYbzXjuogZcAuuZKVWY3ES2iElKZLr24oCZbHWljPV4o griHzfbmHYI= =54L7 -----END PGP SIGNATURE-----

1 0

Re: Digicash: good description
by stig＠netcom.com 17 Dec '03

17 Dec '03

In <01H3JF7JM47M8WXVML(a)delphi.com>, Mike Ingle wrote... > Does anyone know where I can get a good, lucid ASCII description > of digicash systems? > > --- MikeIngle(a)delphi.com > I haven't tested it, but I pulled a postscript to ascii converter off the net recently (alt.hackers I think)... I'll make it available as netcom.com:/pub/stig/src/gsascii.shar.gz Stig ;; __________________________________________________________________________ ;; Stig(a)netcom.com netcom.com:/pub/stig/00-PGP-KEY ;; It's hard to be cutting-edge at your own pace... 32 DF B9 19 AE 28 D1 7A ;; Bullet-proof code cannot stand up to teflon bugs. A3 9D 0B 1A 33 13 4D 7F

1 0

Re: Orange book, the NSA, and the NCSC
by cme＠ellisun.sw.stratus.com 17 Dec '03

17 Dec '03

>Message-Id: <m0ohwxY-00022PC@khijol> >From: khijol!erc(a)uunet.UU.NET (Ed Carp) >Subject: Re: Orange book, the NSA, and the NCSC >Date: Wed, 29 Sep 1993 01:32:27 -0800 (PDT) >Even if a Cray can crack a PGP-encrypted message in, say, an hour, flooding >the system with messages would tend to obscure real traffic with obscure >junk. Hey, I can encrypt /vmunix with a random key as fast as the next >person. :) I still have my copy of (what I call) pgp-ran. I forgot what it was called when it was posted and I can't find the sources now. It puts rannos in PGP format. Does a copy of the sources exist on one of the servers? It's too fast to be doing any encryption but it would be good to have one which produces messages PGP recognizes as real, only for a public key which isn't on file. If PGP rejects a message, it wouldn't take up any Cray cracking time. - Carl Sample: -----BEGIN PGP MESSAGE----- Version: 2.1 tJaHof1c+6P+Llz8D7E4Nt7sETVMtqqazEhcjX4hRIgdtTZwPeocLjIP3dbkIF+7 JfXt2QOIYulFC+1RcdtoA233TTbbYZXi5uPv+d3WMcbObQf3tMfuCXlWqBxCaIkT 3zD1R6MdXnry4KplWJTZg5vK6gMUpxogkrV1lhS8J9uBHYmeh63BzmLtGXBvIpPt Uli6G12PylQ693YexPfk1qR7BSrK863QfZKmOB1BmG7j9TBuigSXKjSL19Vx4MCX mM90Nz1z5wW2DXkl328BZPNOMiAEvCcVOZJcM/PFvm7z9fY1VV2ukD9wm91V/RqN ZNm1/glIyDLCSgq3VqnQfzpzeqrWTCksQLhPrGYdJjgcDKTY07oTuRHM7yjO0H7E ScU9jsbsP7ISFcr6XTNFlUSgG1v78q/PGTMp/nWOieho6MiRfvXEEplKeUFa+FpE Y2uYdEmAiHodTKuz5F39ucIMwNnuSQzrGhDklpkHxMkEWT3PYvNHLVT8i6q1LdgR +j1jMZr9lPC7i5L7oYC0tVwPQaEb4ks2HiaU7FRhUTc3Nny1/0psJZ8Z0A0slhis D8A+BSfWl8Nyj/ojzRP8rLWfMKLxrtduqetrwMBVIOIsNwPABe9sqTL2dWnJEE3u kZSxbo5pwl3g03hT0O9HZzlwau0eliBK7T =7W70 -----END PGP MESSAGE-----

1 0

Re: Disturbing statistics on wiretaps
by cme＠ellisun.sw.stratus.com 17 Dec '03

17 Dec '03

>From: "George A. Gleason" <gg(a)well.sf.ca.us> >Subject: Re: Disturbing statistics on wiretaps >Message-Id: <93Sep29.023420pdt.14278-2(a)well.sf.ca.us> >Date: Wed, 29 Sep 1993 02:34:18 -0700 >And of course it should be remembered that there is still an old drug-war >thing on the books which allows 72 hours' interception without a court >order. Now depending on how that's interpreted, 72 hours are a lot of >conversations. This stuff can be used for background intelligence and >investigation where it never winds up in court but is used to get >information to be used in other ways. "It's what they don't tell you..." This can't be true. I read DERD's paper on wiretap law and she certainly didn't mention anything like this. You must be making it up. :-) ? No, :-( - Carl

1 0