June 1993 - cypherpunks-legacy

Re: Blasting Bidzos Blather
by Fred Heutte 18 Jun '93

18 Jun '93

> PKP is not going to go away when a few of its patents expire. Right. Contracts and licensing arrangements can last much longer than patents. That's why it's so important to see the exact details of this latest deal and find out why someone in the federal bureaucracy was greasing the procurement skids.

1 0

Re: "RSA sells out" hue and cry (fwd)
by dmandl＠lehman.com 18 Jun '93

18 Jun '93

> From: "George A. Gleason" <gg(a)well.sf.ca.us> > > I'm not so sure that all this Bidzos Biz is as evil as it may sound. > Consider the management have an obligation to the stockholders to make > money. Now here is a huge market. Do they turn it down on the basis of > political rectitude...? I don't run my life based on a spreadsheet. There are plenty of very profitable things I could do that I don't because I think they're scummy. The makers of napalm didn't take "political rectitude" into account either; nor did those bastards (Dow Corning?) who knew the truth about breast implants but hid it to protect their bottom line. Sorry, but I find this attitude extremely disturbing. > Are we seriously expecting that Bidzos will refrain from tapping into this > market, and refrain from charging a cent for an RSA-PGP thing...? Oh, okay, > so he's supposed to go into poverty to prove his ethics. Oh, I see. Gee > whiz, I thought I was the most socialistic of anyone on this list. > > -gg I'm not expecting anything of the kind. I'm not a capitalist, so it's not my job to work out these contradictions. --Dave.

1 0

Re: "RSA sells out" hue and cry (fwd)
by George A. Gleason 18 Jun '93

18 Jun '93

I'm not so sure that all this Bidzos Biz is as evil as it may sound. Consider the management have an obligation to the stockholders to make money. Now here is a huge market. Do they turn it down on the basis of political rectitude...? Are we seriously expecting that Bidzos will refrain from tapping into this market, and refrain from charging a cent for an RSA-PGP thing...? Oh, okay, so he's supposed to go into poverty to prove his ethics. Oh, I see. Gee whiz, I thought I was the most socialistic of anyone on this list. -gg

1 0

Re: Contempt of court
by George A. Gleason 18 Jun '93

18 Jun '93

One-time pads for coerced confessions: Consider that the cyphertext of an OTP could come from *any* combination of plaintext and keystream. Okay, now you have in hand your cyphertext of an original file having to do with your lawsuit against the govt. Take that cyphertext, and get another file of equal or longer length which is completely innocuous, for instance some mild-sounding diary entries or some such. Now XOR these together, and what pops out is the *keystream* which *would have been used for encyphering the innocuous plaintext into the cyphertext you have there. Okay, now you have five files: 1) your original plaintext re your lawsuit against the govt. 2) the keystream which converted that into the cyphertext below. 3) the cyphertext. 4) the innocuous text file for instance edited journal entries. 5) the "keystream" which resulted from XORing (3) and (4), which can be claimed to be the keystream which was used to encypher (4) into (3). Okay, now Big Brother comes to get you and coerce you to decypher your file, but you don't want your attorney-client confidentiality violated, so you hand over items (3) and (5), and when Big Bro "decrypts" (3), out pops (4) thereby proving that you aren't the dastardly subversive who is trying to sue the govt...! "Dear diary..." -gg

1 0

Shorter PGP keys
by remail＠tamsun.tamu.edu 18 Jun '93

18 Jun '93

I was thinking of trying to come up with a short form of my PGP key. Very few people put their PGP keys into their .sig's any more because they are so lengthy. Here is my key, 1024 bits, as it would normally appear: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK----- This has a couple of signatures on it and is pretty long. I stripped the signatures, figuring that people can get them from a key server, and that helped quite a bit. Also, the "Version: 2.x" line is not currently used, and if you eliminate it you don't need the blank line after it. Also, the last line is a checksum for the key and in today's internet environment you don't have to worry about noise that much. Stripping all these gives: -----BEGIN PGP PUBLIC KEY BLOCK----- mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPg== -----END PGP PUBLIC KEY BLOCK----- This is pretty compact and wouldn't be bad in a .sig. We've gone from 12 to 6 lines. I wish there were a mode in which PGP would scan a file looking not for "-----BEGIN PGP" but rather for lines which are exactly 64 lines long and contain just the RFC1113 (or whatever it's called now) character set. I realize it would get fooled by PEM but maybe the user would only run it if he knew it was a PGP file. Then you could reduce the key to four lines. If you were willing to use a 512 bit key, good enough for casual use, you could get it down to 3 lines. This is probably an appropriate level of privacy for people on multi-user workstations (i.e. as much privacy as they can expect). Hal Finney -- 74076.1041(a)compuserve.com -- Stripped PGP key: mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPg==

1 0

OTP dual decryption
by nobody＠eli-remailer 18 Jun '93

18 Jun '93

-----BEGIN PGP SIGNED MESSAGE----- Using a one-time pad for dual decryption might work like this. I have a file, D (for Dangerous), which I want to conceal. I construct a random file of the same length, K (for Key), which will be my "encryption key". I xor K and D to produce E (for Encrypted), the encrypted file. I delete D and hide K somewhere. Now, in case an intruder steals E and coerces a decryption out of me, I prepare S (for Safe), a file containing some safe plaintext. I xor S and E to produce F (for Fake), the fake key file I will be able to present. I destroy S and hide F somewhere, but perhaps not as securely as I hid K. Now, if the intruder comes, he finds E, the encrypted file. He demands the key, and I explain that the file was encrypted with a one-time pad, and here is the key, and I provide him F. He xor's F and E to find S, the safe plaintext, and I am protected. This is all well and fine, but it depends on successfully hiding K, the actual key file. But if you can successfully hide files, it seems to me that you might as well have just hidden D, the dangerous file, in the first place, in whatever hiding place you were going to use for K. Then substitute S, the safe file, for D. This is just the old idea of having two sets of books for a crooked business, one innocent and public and one incriminating but hidden. So I'm not sure the one-time pad idea really helps much since if you can meet the requirements to use it you might as well just hide your data the old-fashioned way. Are there any advantages that I'm overlooking? Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLCEucqgTA69YIUw3AQFBlAP/ZHeOKs71H2d0HD2vLwupRB/TwzuEy7dD iE91swoYo8FK5a66DAi8f2kmDIqoiPai+jieI/506zWFuHJRiCW7PLs6v8ga4Aj6 WglBJ1ksOlY74X6qrlykw3kXMjX6x8t7lbp+e6R7Fy67n6gUSGaRozyniv3JusrY c7wXxxh9rvs= =AAV7 -----END PGP SIGNATURE-----

1 0

Computer Shopper encryption
by nobody＠alumni.cco.caltech.edu 18 Jun '93

18 Jun '93

If Kragen's RNG from Computer Shopper is called repeatedly with range=256, so that the resulting values are in the range 0-255 for xor'ing, it is very weak. That will mean that the RNG will repeat with period of at most 256, and so the only question is which of the 256 possible starting points was used. In other words you only need to do 256 trial decryptions (just try seeds from 0-255) and you've got it. Using the low-order bits of an LCM RNG like this one is a bad idea. You should use the high order bits, or use a range which is not a power of 2 so you end up using all the bits. Even then LCM RNG's aren't crypto- graphically strong, although from what I have seen the techniques of breaking them are what a layman would call complicated. Compared to breaking, say, DES, though, they are no doubt trivial. Hal Finney 74076.1041(a)compuserve.com

1 0

Re: xor w/prbs
by bear＠eagle.fsl.noaa.gov 18 Jun '93

18 Jun '93

>How *do* you break this cypher? He is generating a lot of random numbers >between 0 and 255, and xor'ing each successive one with the next byte of plain- >text. I know that this is a trivial cypher to break, according to PRZ at >least, but how do you do it? In this case, since the modulus is a small power of 2, you can do exhaustive search. There is _one_ sequence of 256 distinct values. Still want to know how long it will take to crack his ciphertext? >#define MULTIPLIER 0x015a4e35L >#define INCREMENT 1 > >long RandomSeed; > >int GetRandomNumber(int Range) > { > RandomSeed = MULTIPLIER * RandomSeed + INCREMENT; > return(RandomSeed % Range); > } > >So how do you crack this cipher without trying all the keys, guys? Since max_integer / gcd (range, max_integer) > range you can move the modulus operation around without worrying about weird effects from the finite word size. This is because the closed form of the loop is: seed[k] = (seed[0] * mult^k + incr * sum (j = 0 to k-1) of mult^j) % range which is equal to seed[k] = (seed[0] % range) * (mult % range)^k + (incr % range) * sum (j = 0 to k-1) of (mult % range)^j and the modulus operation with a power-of-2 range simply keeps the last n bits. But, this also means there are effectively only "range" possible values for the initial seed. Even if you make the increment and multiplier part of the key, they must (both?) be odd so you only have 22 bits of key. Of course at this point you can simply use the fact that this "one time pad" is actually a Vigenere cipher with 256 columns -- easy to crack if you have some insight into the nature of the plaintext (e.g., English text). For instance, 10-15 small documents (40 lines) encrypted with the same key is enough to crack it even if the multiplier and increment are unknown but constant. Bear Giles

1 0

xor w/prbs
by TO1SITTLER＠APSICC.APS.EDU 18 Jun '93

18 Jun '93

Some MORON wrote an article in Computer Shopper, about doing a one-time pad with a PRBS... in fact, he even challenged any cryptographers to break it. (He used a 32-bit seed for the PRBS.) He also included a number of fallacies in the article, among them that you change your algorithm when you think the enemy knows what it is, but you change your keys regularly even when you don't have any basis to think so. How *do* you break this cypher? He is generating a lot of random numbers between 0 and 255, and xor'ing each successive one with the next byte of plain- text. I know that this is a trivial cypher to break, according to PRZ at least, but how do you do it? This arrogant moron with pretensions to cryptographic knowledge needs to be corrected. (Some might say the above epithet applies to me too, to which I reply: I don't pretend to know crypto. I just read cypherpunks.) He is: David Stafford, care of Computer Shopper ONe Park Avenue New York, NY 10016 This kind of misinformation is dangerous to the public at large. The article is on page 558 af the July, 1993 Computer Shopper. It uses a random number generator, (now that I look, it's not a PRBS) from the June, 1993, Computer Shopper, by the same author. The random number generator used is like this: It uses a global variable called RandomSeed, and each time thru the random function, RandomSeed, a 32-bit long, is multiplied by 0x015a4e35, and incremented; and then the new Randomseed, modulo the largest desired return value, is returned. (Actually, mod the largest desired value +1.) a code fragment: #define MULTIPLIER 0x015a4e35L #define INCREMENT 1 long RandomSeed; int GetRandomNumber(int Range) { RandomSeed = MULTIPLIER * RandomSeed + INCREMENT; return(RandomSeed % Range); } So how do you crack this cipher without trying all the keys, guys? Kragen

1 0

Blasting Bidzos Blather
by L. Detweiler 18 Jun '93

18 Jun '93

The following message is FOR CYPHERPUNKS ONLY. I specifically *prohibit* further distribution past the mailing list! Please do not betray my trust! [Bidzos] >I'm genuinely > confused, as I believe the situation is as simple as I put it to you. > Our claims of patent infringement by DSS, made over the last 18 > months, were well-known and publicized. NIST has capitulated. Seems > pretty straightforward to me. The more I read from Bidzos, the less I believe he has any overall control or even awareness of the company, or is purposely duplicitous. His vague and weak defenses I find personally intelligence-insulting. DSS seemed to defy the face of all public input into the standard, which opposed the NIST algorithms (`handed down' in a dictatorial and authoritarian manner, sound familiar?) in favor of RSA. How is it that Bidzos makes no reference to this? Apologists for DSS such as Denning do so on two major grounds: 1) it is part of the larger plan involving Clipper, therefore lack of duality in encryption and authentication features (an implicit characteristic of RSA) is not a problem 2) the security is `no weaker' (cunningly disguised as to appear to say `better') than RSA. Both are noxiously misleading arguments in themselves, but are also decoys (like key escrow agencies and procedures) to the critical issues at stake. The critical point is that even the *appearance* of a `fair and impartial' standards making process was totally defied, to the point of suggesting a complete clandestine backroom collusion! (hm, sound familiar?) But gosh, I wonder how many people would have advocated RSA back then when they could predict the future: that NIST would not only embrace PKP but would award them a complete monopoly on signature standards. Somehow proponents of this new NSA-Clipper-Capstone obscenity are now pointing back to history and saying that the main objections to DSS standards were *technical* (strength of the algorithm) and *legal* (PKP patenting) and that they have been wholly ameliorated by improvements (in key size) and recent events (PKP support). This is historical revisionism at its worst! From my point of view, critical main objections were on the warped process that permitted an unpopular (and perhaps even subversive) standard be adopted! This revisionism definitely suggests something deeper and `ulterior' is going on---that a comprehensive NSA-PKP alliance is in place? > BTW, on Clipper, ATT, Motorola, IBM could have done Clipper without > ever talking to us. Contrary to popular belief, we don't dictate > terms to licensees. First, I find it absolutely ridiculous for an informed agent of PKP, and for that person to coincidentally be called the *president*, to claim that `we don't dictate terms to licensees'. This is only true in the sense that if the licensee does not agree to the terms put down by PKP, they don't get the license! Second, I would like to see PKP contracts. There are probably more clauses than a bad run-on sentence. I'll go out on a limb and wager that PKP *does* limit the use of RSA in the company's products, and that the licenses are fairly specific. It seems rather inconceivable to me that any such corporate agreement that could be so simplistically summarized as `PKP gives rights to company [x] to use RSA in *any* of their products as long as they pay [y] royalties'. The agreement is very likely product-specific and implementation-limiting. Perhaps Mr. Bidzos or representatives of companies involved would be willing to forward copies of these agreements for our consideration of Mr. Bidzos' claims, assuming they are not `classified'... Third, regardless of presence of product-specific limitations in the licenses, and even if PKP has sold licenses to companies that somehow permit them the latitude to include RSA technology in their Clipper implementations, PKP can certainly take the future stance that they will prohibit that use in future corporate contracts! If Mr. Bidzos really thinks that Clipper is `ill-conceived, ill-timed, and undesirable' perhaps he should figure out how to keep his company from supporting, nay, *promoting* and *profiting* from it. Let's look again at the announcement: >PKP will also grant a license to practice key management, at no >additional fee, for the integrated circuits which will implement >both the DSA and the anticipated Federal Information Processing >Standard for the "key escrow" system announced by President Clinton >on April 16, 1993. `at no additional fee'? What does that mean, `for free'? This apparently means Mycotronx, despite being a private company, does not need to license (read: pay for) the RSA patents on the critical key-exchange function for use in Capstone for *any* implementations (public or private), nor does any other company NSA decides to induct into its privileged enclave. Hm, I wonder how RSA's other `customers' feel about that? And why would PKP voluntarily give up this potentially valuable revenue source? Clipper implementations could be *extremely* lucrative for PKP. That they don't license them specifically, and in fact voluntarily give up the perogative to do so, suggests that they gave up something greater in return for them. Namely, the award of an official U.S. government-endorsed monopoly on DSS and arguably all valuable cryptographic techniques. By the way, let's look Mr. Bidzos' quote on Clipper. Clipper is `ill-timed'? What does this suggest, that a NSA-PKP partnership would be better served if it came out sooner or later? Clipper is `ill-conceived and undesirable'? For who? Was it that PKP perhaps didn't hear about it soon enough to rob all the tasty new cryptographic algorithm patents surrounding it, like it did with the Schnorr patent? The licensing notice (which was probably reviewed and approved by PKP representatives) refers to Clipper as `an anticipated Federal Information Processing Standard?' How, Mr. Bidzos, can this new revelation possibly be construed to indicate that Clipper `will go away'? Yes, I suppose Mr. Bellovin was right. The omnipresent underlying message here is that nothing is unethical if PKP profits from it. I advise cypherpunks not to take Mr. Bidzos' comments literally. They are, however, interesting from the perspective of the study of the speech of either an uninformed figurehead or a capitalist (or even nationalist) co-conspirator. P.S. all cypherpunks `for' an alliance with PKP, please raise your hand. I personally find the image of `lumbering but ultimately benevolent corporation' too incredible to hold in the face of recent events, and am now actually quite embarrassed to have advocated some `good faith' proposals involving the company which look naively misguided in hindsight. PKP is not going to go away when a few of its patents expire. To the contrary, it appears to be clutching everything within reach to ensure its eternal domination in the commercial cryptographic field. (sound familiar? a PKP-NSA alliance makes perfect sense.)

1 0