December 2003 - cypherpunks-legacy

Re: FIDOnet encryption (or lack thereof)
by doug＠netcom.com 17 Dec '03

17 Dec '03

J. Michael Diehl <mdiehl(a)triton.unm.edu> said: According to Mike Godwin: >> examining the mail that passes through his system, it seems likely that he >> is violating the Electronic Communications Privacy Act. > >That was my first question. Then it occured to me that I have seen bbs's which >have disclaimers wrt email privacy. That is the loophole he is exploiting. I haven't kept up on this, so correct me if I'm wrong, but I thought that BBS's had a choice as to whether to operate as Common Carriers or not, as long as they were strictly consistent. If they want to be categorized as Common Carriers then they have to have strict policies of hands-off privacy, are not liable for the content of messages on their board, and the ECPA applies. But if they do not guarantee privacy, do not perform any kind of censorship or other control of message contents, then they are not Common Carriers and the ECPA does not apply. Prodigy would be an example of the former, Internet email & news would be an example of the latter. Yes? No? Is this stale, ancient, and incorrect info? Or if the concept is correct, is the problem that they are merely forwarding email from systems that *are* CC's, and so the ECPA applies to that particular service, whether or not it applies to the rest of what they do? Doug

3 2

Communications Week Article
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

In the Sept 28 issue of Communication Week, Pg 35-36. _Who will hold the Clipper Keys?_ *Last Paragraph* The administration will choose the escrow agents based on experience in handling sensitive information, according to the EFF report. It will avoid choosing low enforcement agencies to avoid conflicts of interest and it will not choose private companies because of concerns about the companies' longevity, the report said. Well hmm... what about the longevity of governmental agencies, or even the government itself?

1 0

Re: Active Eavesdropping of Clipper Phones
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

There are a variety of ways around Diffie-Hellman spoofing. The current STU-III phones from AT&T, Motorola, etc., use several approaches - there's the Crypto Igniter Key dongles that you need to authorize your phone, which provides one form of out-of-band authentication (partly authentication of the DH keys, but more important is authentication that the person at the other end is probably cleared for the level of classification you're running the call at); there's also an LCD display on the phone that shows the other person's DH half-key, so you can do voice verification if you want. They may do other stuff as well. Scott Collins mentioned the "digital signature on RSA keys", which the Capstone phones probably do even though Clipperphones probably won't. There are also tricks about sending half the key at a time, though they're apparently still hackable. Bill

1 0

DES Implementations
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>koontz-des.tar.Z >David G. Koontz <2004ktz%ucsbuxa(a)hub.ucsb.edu> >Fast but large DES C functions and main program. >Dates to March 1991, at which time it was one of the fastest around. >Good verification suite included. I have three or four faster versions, when I think about it I try and produce smaller code (Cache size limits, don't you know)

1 0

POISON PILL
by Sandy 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort(a)attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Punksters, Here is probably one of those dumb questions we non-technical types ask from time to time on this list. Please indulge me though, in case there is something to it. In today's America, we live under the constant threat of police seizure of our computer equipment and other assets. Of course, we can encrypt the information our files, but this is, at best, a passive solution. Are there any positive actions we can take? POISON PILL--What, if anything, can be done to booby-trap a computer? Once the cops have a machine, one would expect that they will paw through everything in it. In addition, they will probably use the stolen computer for their own data processing needs. What could be done have the computer screw up the cop's data days, weeks or months after the seizure? Of course, I would never do such a thing myself, nor would I advise anyone else to do so. I do, however, have a passing academic interest in the subject. Same for you folks too, right? S a n d y >>>>>> Please send e-mail to: ssandfort(a)attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4 3

FIDONet Censorship?
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

FIDONet operators are sometimes blocking encrypted messages. So what else is new? Their machines, their rules. Strictly speaking, this is not censorship. However, we can try to get them to change their rules. Better, route around such machines. John Gilmore has one of the best lines I've seen on this, quoted in the new book by Howard Rheingold (something about "Living on the Virtual Frontier," just out in the stores). John says something along these lines: "The Net tends to view censorship as damage and routes around it." -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it.

2 1

EFF RESPONDS IN PGP CASE
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

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

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

How about a pgp RFC...
by Brad Huntting 17 Dec '03

17 Dec '03

If you've followed the PEM working group in recent years, you may have come to the conclusion as I have that it is not going anywhere, and probably never will. In an effort to make e-mail crypto more wide spread, I suggest we draw up an internet-draft on the PGP message format, and the algorithms used to send and receive messages. At the moment I can think of nothing PEM can do that PGP cant. Granted there are problems scaling the web-of-trust model, but PGP is also capable of using a top down model (really just a subset of the web model). One thing such a draft is sure to do is send a clear signal to the PEM group that they must either start swimming or sink. brad

4 3