- cypherpunks-legacy - lists.cpunks.org

re: Registering Keys...
by Tom.Jennings＠f111.n125.z1.FIDONET.ORG 27 Oct '92

27 Oct '92

U> From: 74076.1041(a)CompuServe.COM (Hal) U> This proposal to register keys was also mentioned in the U> July, 1992 Communications of the ACM, in an article by Ron U> Rivest, one of the creators of the RSA algorithm. He was U> solution based on 'escrowed secret keys' might be U> workable, wherein each user is legally required to depost U> his or her secret key with a trusted third party, such as U> the user's bank. Actually this sounds signifigantly different from what Denning is allegedly proposing. This method is analogous to the way FFL (Federal Firearm License) holders record transactions of gun sales (I have an FFL). FFL holders are required to record, in detail, each transaction based upon gun serial number/description, and to/from addresses (buy/sell). The FFL holder maintains the records; the feds dont' get a copy. If a gun is used in a crime, the feds go to the manufacturer, and follow the audit trail of FFL records to follow that guns travels. This is *completely* different than a centralized gun database, where a hypothetical they can compile cross indices based upon oh say name or address or whatever. The third party escrow method puts the same sort of restraint upon searches. I'm not saying I particulary like the method, it's just that it's qualitatively different. The BATF cannot rummage through the audit trail of FFL records, they can only follow the forward/backward pointers per gun. Rivest seems to imply there could be many, independent key-escrow locations. A hypothetical we could form our own key escrow, and while we'd be subject to whatever the hypothetical they would require for access, we could probably do things ilke inform members of all key accesses/inquiries, etc. In short, it bothers me a lot less than Dennings. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings(a)f111.n125.z1.FIDONET.ORG

1 0

Re: Alpha Particles and One Time Pads
by George A. Gleason 27 Oct '92

27 Oct '92

Re Pete's proposal for an on-net random source which could be accessible to users who would then use a psuedo-random process to select which bits to use in compiling cypher keys: What you'll get will be superencipherment, which is no more secure than the links in the chain. The random stream would be non-secure; and so we're left with the security of the psuedo-random selection process. To analogise somewhat, white noise put through a filter has the characteristics of the filter. Try it with FM static and a graphic equaliser. Now to play devil's advocate here, I wonder if a less-than-perfect physical random source would be acceptable, since the potential domain of decryptions would be large enough that unicity in cryptanalysis would in practice be unattainable. What do you think...?

1 0

(fwd) A Trial Balloon to Ban Encryption?
by tcmay＠netcom.com 27 Oct '92

27 Oct '92

Fellow Cypherpunks, I have rewritten my posting on Denning's proposal and posted it to sci.crypt, for wider discussion. I'm surprised the sci.crypt folks had not already the significance. You might want to consider debating the issue there, rather than on this list, as your words will then be heard by more folks and could mobilize an effort against proposal like this one of Denning's. Cryptically your, --Tim Newsgroups: sci.crypt Path: netcom.com!tcmay From: tcmay(a)netcom.com (Timothy C. May) Subject: A Trial Balloon to Ban Encryption? Message-ID: <1992Oct26.180813.7002(a)netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 Date: Mon, 26 Oct 1992 18:08:13 GMT Is there a trial balloon being floated to effectively ban encryption? Noted and influential influential crypto advisor Dorothy Denning has apparently floated the idea of _public key registration_ in a paper or talk at the 15th Computer Security Conference in Baltimore, held recently. Discussion of this is in comp.risks ("RISKS"), so far, but certainly belongs in this group. I posted a summary of this position to a private mailing list devoted to crypto issues and got a huge response of concerned folks. I don't understand why this is not a hot topic on sci.crypt, so I'll post something right now. Here's my understanding of her proposal: * Anyone using public key cryptography would be required to register the private key with the appropriate authorities, for example, the Justice Department. * To head off the obvious concerns about the government routinely reading e-mail, financial dealings, etc., this registered key would be stored at an independent agency after first being encrypted with the _public key_ of Justice. (That is, the independent key storage agency would have an unusable key, so _they_ couldn't use it themselves.) * To obtain a usable form of the private key, Justice would have to get a valid court order, go to the independent storage agency, present the order, pick up the key, open it with their own _private key_, and proceed to open mail, read communications, etc. This is ostensibly the procedure now used for wiretaps. But the effect on encryption would be chilling: -would greatly complicate the rapid changing of keys -would probably be a way to get "unlicensed" crypto programs off the market (e.g., don't think about using PGP 2.0, as the key registration authorities would either insist on another algorithm, or would send the "registration application" to, for example, RSA Data Security for legal action) -would undoubtedly require a "fee" (like a driver's license) -would interfere with the use of digital pseudonyms, anonymous nets (a la Chaum's "DC Net" proposal, which some of us are exploring now), and digital money -would establish the precedent that private communications are not legal, that copies of all private communications must be placed in escrow with the government Registering keys is no different than, for example, requiring a permit for every public utterance or for registering typewriters, modems, computers, fax machines, and copiers. Or banning the use of sealed envelopes for mail. In Phil Zimmerman's great words, it would be like requiring all mail to be sent on postcards. My suspicion, which Prof. Denning will presumably comment on if she's reading this, is that the government folks have come to understand the profound implications of modern crypto and are looking for approaches to head off the coming sea changes. Granted, there are serious national security threats in using modern crypto methods, but there are in any of the new technologies, such as those listed above. Besides, does anyone think all keys will be registered? Hiding bits is a relatively easy thing to do. This key registration proposal is more odious than the "backdoors in telecom equipment" proposal discussed here recently. Can we remain silent as our liberties are taken away? I think it was John Gilmore who said: "If encryption is outlawed, only outlaws will have encryption." -- .......................................................................... 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 | PGP 2.0 and MailSafe keys by arrangement.

2 1

Re: Registering Keys with Big Brother
by Arthur Abraham 27 Oct '92

27 Oct '92

Seems to me that there would be a certain amount of trouble with people registering one private key but communicating with another they had forgotten to register. Bad situation for my large sibling 'cause he wouldn't realize this until after the court order etc. A good solution would be BIG fines for mis-encryption and sampling of messages to make sure they were properly formed -- for our own protection, of course. And if they happened to radomly sample something they didn't like... for instance finding my obviously excessive paranoia.... -a2.

2 1

Alpha Particles and One Time Pads
by tcmay＠netcom.com 26 Oct '92

26 Oct '92

Fellow Cypherpunks, Here's a posting I just sent to sci.crypt, dealing with using alpha particle sources as noise sources for generating one-time pads. Ordinarily I wouldn't bother you folks with this, especially since you're all reading sci.crypt (aren't you? Only the FidoNetters have a good excuse not to.). But this thread ties together two aspects of my life, cryptography and alpha particle errors in chips. --Tim Newsgroups: sci.crypt Path: netcom.com!tcmay From: tcmay(a)netcom.com (Timothy C. May) Subject: Re: Hardware random number generators compatible with PCs? Message-ID: <1992Oct26.051612.29869(a)netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 References: <1992Oct25.224554.1853(a)fasttech.com> Date: Mon, 26 Oct 1992 05:16:12 GMT Bohdan Tashchuk (zeke(a)fasttech.com) wrote: : The recent post on building a random number generator using a zener diode got : me to thinking once again about commercial alternatives. : : I haven't seen any commercial alternatives discussed here recently. And since : the market is so specialized, they may well exist but I'm simply not aware of : them. : : The ideal product would have the following features: : : * cost less than $100 : * use a radioactive Alpha ray emitter as the source It's a small world! In my earlier incarnation as a physicist for Intel, I discovered the alpha particle "soft error" effect in memory chips. By 1976 chips, especially dynamic RAMs, were storing less than half a million electrons as the difference between a "1" and a "0". A several MeV alpha could generate more than a million electron-hole pairs, thus flipping some bits. (Obviously the effect of alphas on particle detectors was known, and smoke detectors were in wide use, but nobody prior to 1977 knew that memory bits could be flipped by alphas, coming from uranium and thorium in the package materials. It's a long story, so I won't say any more about it here.) : * connect to an IBM PC serial or parallel port : * be "dongle" sized, ie be able to plug directly onto the port, and : not have a cable from an external box to the port : * be powered directly from the port : * generate at least 1000 "highly random" bits per second This should be feasible by placing a small (sub-microcurie) amount of Americium-241 on a small DRAM chip that is known to be alpha-sensitive (and not all of them are, due to processing tricks). Errors would occur at random intervals, depending on which bits got hit. Getting 1000 errors a second would be tough, though, as such high intensities would also tend to eventually destroy the chip (through longterm damage to the silicon, threshold voltage shifts, etc.). If you really want to pursue this seriously, I can help with the calculations, etc. : Details: : : Certainly in high volume these things can be made cheaply. Smoke detectors : often sell for under $10, and have a radioactive source, an IC, a case, etc. Yes, but smoke detectors use ionization in a chamber (the smoke from a fire makes ionization easier). That is, no real ICs. But ICs, and even RAM chips, are cheap, so your $10 figure is almost certainly in the ballpark. A bigger concern is safety, or the _perceived_ safety. Smoke detectors have, I understand, moved away from alpha particle-based detectors to photoelectric detectors (smoke obscures beam of light). Don't underestimate the public's fear of radioactivity, even at low levels. : Using a well-designed circuit based on Alpha decay should mean that the : randomness is pretty darn good. But not necessarily any better than noise from a Zener. With the higher bit rate from diode noise, more statistical tricks can be done. The relatively low bit rate from alpha decay gives less flexibility. On the other hand, alpha hits are undeniably quite random, with essentially no way to skew the odds (unlike with diode noise). : Everyone these days has either a serial or parallel port available, either : directly or thru a switch box. : : The tiny "dongle" size is a convenience. If it is small and powered directly : from the port, there are no cables to get in the way. There is enough power : available from the signal lines on these ports to power simple devices. E.g. : most mice don't require an external power supply. : : For most applications 1000 bits per second should be adequate. For example, : it would be quite adequate for session keys. For generating pseudo : one-time-pads, an overnight run should generate plenty of values. Continuously : generating values for a month would produce about 300 MB, which should be : enough to exchange new CD-ROM key disks once a month. One time pads are complicated to use. Only very high security applications that can also afford them use them. For example, some diplomatic traffic. I can't conceive of a case where 300 MB a month could be used. And _theft_ (or copying) of the CD-ROM one time pads has got to be a much bigger issue that whether alpha particle noise sources are better than diode noise sources! By about 10 orders of magnitude I would say. Black bag jobs on the sites holding the keys will be the likeliest attack, not trying to analyze how random the noise is (even a fairly crummy noise source will not yield enough information to a cryptanalyst trying to break a one-time pad). Having said all this, I'm glad you gave some thought to alphas. For a time in the late 1970s this was the chip industry's number one headache...it was definitely the most exciting time of my life. --Tim -- .......................................................................... 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 | PGP 2.0 and MailSafe keys by arrangement.

3 2

entropy, with code
by Eric Hughes 26 Oct '92

26 Oct '92

The entropy-calculating code is at the end of this message. I took the opportunity to calculate some sample entropies: entropy.c 5.283772 the source code entropy.asc 6.052222 entropy.c, encrypted and armored entropy.as2 6.012493 entropy.asc, with the wrappers removed entropy.pgp 7.830532 entropy.c, encrypted alone entropy.obj 6.112890 entropy.exe 6.947111 randseed.bin 4.584963 from pgp, 24 bytes long pubring.pgp 7.754017 my public key ring The entropy of the source code is in the high end of the range for English, which is not surprising given the amount of symbols in ordinary C code. The entropy increases with the object and the executable, each of which has less overt structure to it. The entropy of the encrypted and ascii armored source code is within 1% of 6 bits, just as predicted. And with the wrappers removed, it's even closer! The binary version of the encrypted message has the highest entropy of all these tests. In randseed.bin, the entropy is much less than 8. But the length of the file is 24 bytes and log_2 24 = 4.584963, indicating that there are no duplicate bytes in the file. Hence the warning: entropy calculations with small samples _will_ be misleading. Note that the entropy subroutine can be used to calculate the frequencies of any distribution. This will allow all you code-writing cypherpunks to measure bit entropies, digram entropies, etc. Eric ---------------------------------------------------------------- /* entropy.c -- Calculate monogram entropies of standard input. */ #include <stdio.h> #include <math.h> /* This next define is to counteract the foolish C 7.00 runtime mapping * of \x1A to EOF */ #define STUPID_NEWLINE_TRANSLATE 1 #ifdef STUPID_NEWLINE_TRANSLATE #include <io.h> #include <fcntl.h> #endif /*--------------------------------------*/ #define NUMBER_OF_BYTES 256 long byte_freq[ NUMBER_OF_BYTES ] ; void main() { int c, verbose = 0 ; unsigned int j ; double entropy( long *, int ) ; #if STUPID_NEWLINE_TRANSLATE _setmode( _fileno( stdin ), _O_BINARY ) ; #endif for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) { byte_freq[ j ] = 0 ; } while ( EOF != ( c = getchar() ) ) { ++ byte_freq[ (unsigned int) c ] ; } if ( verbose ) { for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) { printf( "%3d=%-3d ", j, byte_freq[ j ] ) ; if ( j % 8 == 7 ) printf( "\n" ) ; } } printf( "%lf\n", entropy( byte_freq, NUMBER_OF_BYTES ) ) ; } /*--------------------------------------*/ /* Calculates the entropy of the distribution given in list v of n elements. * The list v gives counts. v is summed, and frequencies are assigned * as v[i]/sum(v). * * Uses the following definitions and identities: * A = \Sum_{i=0}^{n-1} v_i * p_i = v_i / A * H = \Sum_{i} - p_i \log p_i * = log A - 1/A \Sum_{i} v_i \log v_i * lim_{x \rightarrow 0} x \log x = 0 */ double entropy( long *v, int n ) { double h ; long sum ; int j ; /* first sum the array */ sum = 0 ; for ( j = 0 ; j < n ; ++j ) { sum += v[ j ] ; } /* next calculate the entropy function */ h = 0 ; for ( j = 0 ; j < n ; ++ j ) { /* If the frequency is zero, the entropy contribution is zero */ if ( v[ j ] == 0 ) continue ; h -= v[ j ] * log( v[ j ] ) ; } h /= sum ; h += log( sum ) ; /* Now adjust the base of the logarithm to base 2 */ h /= log( 2 ) ; return h ; }

1 0

Re: Alpha Particles and One Time Pads
by marc＠kg6kf.ampr.org 26 Oct '92

26 Oct '92

Tim May sez: Here's a posting I just sent to sci.crypt, dealing with using alpha particle sources as noise sources for generating one-time pads. Tim, Why not use a back-biased germanium diode, or other noisy semiconductor junction? Seriously, the NRC has allowed the smoke detector people to spread those little radioactive chunks of Americium for too long. John Walker of AutoDesk actually built an IBM-PC card that generated random numbers from a radioactive source. All the best, ^M

2 1

Registering Keys...
by Hal 26 Oct '92

26 Oct '92

This proposal to register keys was also mentioned in the July, 1992 Communications of the ACM, in an article by Ron Rivest, one of the creators of the RSA algorithm. He was mostly criticizing the proposed government Digital Signature Standard, stating that he thought that the NSA was purposely trying to get "weak" cryptography installed as the standard. Then he goes on to say, "Are there technical alternatives that would satisfy all parties? Perhaps. It is certainly the case that the formulation of the problem to be solved has never been made explicit for the cryptographic community to work on. I suspect that a solution based on 'escrowed secret keys' might be workable, wherein each user is legally required to depost his or her secret key with a trusted third party, such as the user's bank. Cryptographic hardware and software would only operate with public keys that were certified to having their corres- ponding secret keys appropriately escrowed. A federal agency could then obtain the secret key, or its use, with an appropriate warrant. Once their secret keys were escrowed, multinational corporations could even operate across borders with a high degree of authentication and privacy (except perhaps from court-ordered wiretaps). Cryptographic hardware and software manufactured in the U.S. would not operate abroad without public keys suitably certified as having their secret counterparts escrowed in the U.S. In an extension of this approach, users can escrow their secret keys with several trusted third parties in a 'secret-sharing' manner, so that no single third party can com- promise the user's key. While this approach may have its own difficulties, it does illustrate that weak cryptography is not the only technical approach available. There may be much better techniques for achieving a compromise between a number of conflicting national concerns." At the time that I read this, I thought it was largely a rhetorical device, making the point that if the government wants to infringe on people's privacy, it should come out in the open and do so, rather than skulking about. (Like saying, "if the government _really_ wants to stop sexual immorality it would have to put a TV camera in every bedroom".) And of course (I thought) this kind of proposal would never be taken seriously. I'm shocked that Denning is now advocating it openly. This proposal makes it illegal for people to communicate so secretly that the government can't find out what they are saying. It could apply to postal mail as well as email - it would be illegal to send a message via post which the government couldn't interpret. If this is really the government's purpose, then it should also require that all private conversations be recorded, and the resulting tapes be "escrowed" similarly in case the government needed to find out what was said, for which it would have to get a court order. As Tim suggested, this is probably a "trial balloon" being floated to see what the reaction is. Let's see that it gets shot down. Hal 74076.1041(a)compuserve.com

2 1

Multiple messages + entropy
by Hal 26 Oct '92

26 Oct '92

The Internet PEM (Privacy Enhanced Mail) standard uses the concept which Dean Tribble mentioned of multiple encryption (using each recipient's public key) of a single session key which encrypts the message. PGP's data structures do not currently provide for this but could be extended pretty easily to allow it. On the entropy measure - I thought entropy was how many bits of information you get per character. Encrypted binary text would be pretty close to 8 bits per character. The RFC1113 Ascii encoding used by PGP reduces this to 6 bits per character (e.g. a character set with 64 printable characters) neglecting line separators and message beginnings and endings. So there should be a little less than 6 bits per character for encrypted, Ascii-encoded messages. Hal 74076.1041(a)compuserve.com

2 1

Re: Registering Keys with Big Brother
by efrem＠spitha.informix.com 26 Oct '92

26 Oct '92

It seems that registration would defeat the advantage of a public key system, but it would not prevent private encrypted messages from being hidden from casual traffic analysis or even notice by public key wrapping. This would make registration rather useless against a conspiracy and thus hard to justify in the face of commercial and constitutional opposition. --efrem

2 1