- cypherpunks-legacy@lists.ogf.org

A cite desired...
by Peter Wayner 21 Jun '93

21 Jun '93

I remember reading that IBM originally started looking into cryptosystems like DES after they were informally tipped off that the Russians were evesdropping on their internal network. Can anyone give me a pointer to this fact? Thanks, Peter Wayner

1 0

Patent libraries
by sneal＠muskwa.ucs.ualberta.ca 21 Jun '93

21 Jun '93

Re west coast patent libraries: The two that I've personally used are the Sunnyvale patent library (which Tim May mentioned in an earlier post) and the one at University of Washington in Seattle. The Sunnyvale library is the more complete, with all patents (microfilm for older ones, paper for newer) and gazettes availble. UW only goes back to the mid-sixties or so, but I suspect this will cover all crypto patents. Eric asks: >Do they have electronic access at this library, or is it >paper only? I know they have a fax service for which they charge, >but is there downloadable text available? Both libraries mentioned above have CD-ROM facilities which you can browse onsite. To the best of my recollection, though, the CDs only include abstracts and licensing information, and not the full text of the patents. I'll likely be back in the Sunnyvale area sometime in the next couple of months, but in the meantime, someone might want to verify my recollections about the CD-ROM info. The CD-ROM reader at the Sunnyvale library seems to be heavily utilized, so you might want to call ahead and book some time on it. If you want to check out the UW library and you're not familiar with the area, stop at the UW Visitor's Centre first, or risk getting lost in a strange and bizarre environment. Canadians looking for patent info... don't bother, unless you're in the Ottawa/Hull area, are near a university that has the stuff on CD, or have sufficient connections to get the stuff through CTIS at a reasonable price. Our government (now headed by the flakiest female PC politician this side of Hilary Clinton <sound of stomach churning>) seems to have granted exclusive rights to patent distribution to some bogus little microfiche company in Hull (MicroMedia) that wants some ungodly per-page charge for copying. -- Steve

2 1

Re: OTP dual decryption
by George A. Gleason 20 Jun '93

20 Jun '93

Yeah, the advantage is, if they think they've found it, they might just stop looking much further. It's a chance that might save your ass. -gg

2 1

basic truth
by nobody＠apsicc.aps.edu 20 Jun '93

20 Jun '93

Make it sufficiently difficult for people to do something, and most people will stop doing it. -- Robert Sommer -Forwarded by Nobody.

1 0

that cipher I wrote
by Tyler Yip - UnixWeenie 20 Jun '93

20 Jun '93

Peter Davidson: thanks for the cycle tester!!!!! hadn't thought about testing a generator. As for those generators, they are seeded with the key, but, I messed it up by getting the primes in the wrong order. What characteristics of the multiplier and modulator provide large periods? -- Tyler Yip, UnixWeenie(tm) \ God put me on Earth to accomplish a certain email: davros(a)ecst.csuchico.edu \ number of things. Right now I am so far California State University, Chico \ behind I will never die. -Calvin & Hobbes

2 1

testing pseudorandom number generators
by wet!naga 19 Jun '93

19 Jun '93

Tyler Yip, UnixWeenie(tm), asks: >What characteristics of the multiplier and modulator provide large periods? The standard reference is D. Knuth, The Art of Computer Programming (as I recall), Volume II, the chapter on random numbers. Knuth gives conditions involving a, k and m for n = ( n*a + k ) mod m to have a long (or maximal) period. For the less mathematically-inclined, a pleasing and quick way to eliminate weak pseudorandom number generators is to use the generator to pick row and column pixel positions on a graphics screen. Turn on "randomly" selected pixels. If the screen does not get completely filled in a visibly random way then the generator is weak. A particularly weak generator will turn on 1% or so of the pixels then nothing further happens because it has entered a cycle. A weak generator may fill the screen with parallel lines. Writing a program to test generators in this way is a useful, easy and amusing task and is left as an exercise for the reader. Someone may be inclined to reply that this test does not show that a generator is cryptographically strong, to which the answer is: True, but it certainly eliminates the ones that aren't, and it's fun to watch the pixel display for different generators. Well, on second thought, maybe some generators that are not crypto- graphically bullet-proof might pass this test. But if some generator does not, you can throw it away immediately.

1 0

Trimmed down pgp.hlp
by stig＠netcom.com 19 Jun '93

19 Jun '93

I edited down the pgp.hlp file so that it's more readable (for me anyway). In case you think that the help file is less than helpful, just replace it. PGP maintainers: please add this (or an even more concise version) to the pgp distribution...contrib directory is fine. Stig ------------ Here's a quick summary of PGP v2.2 commands. pgp ciphertextfile [-o plaintextfile] decrypt or verify signature pgp -e textfile her_userid encrypt file w/ pubkey pgp -e textfile userid1 userid2 userid3 multiple recipients pgp -s textfile [-u your_userid] sign plaintext file pgp -es textfile her_userid [-u your_userid] sign, then encrypt pgp -c textfile traditional symmetric cipher only KEY MANAGEMENT: pgp -kg generate your own unique key pair pgp -ka keyfile [keyring] add new key(s) to your keyrings pgp -kx userid keyfile [keyring] extract (copy) a key from a keyring pgp -kxa userid keyfile [keyring] same, except it's ascii pgp -kv[v] [userid] [keyring] view the contents of your public ring pgp -kvc [userid] [keyring] view the "fingerprint" of a public key pgp -kc [userid] [keyring] check signatures of public keys pgp -ke userid [keyring] edit userid/pass-phrase for your keypair pgp -ke userid [keyring] edit the trust parameters for a public key pgp -kr userid [keyring] remove a key (or userid) from your pubring pgp -ks her_userid [-u your_userid] [keyring] sign/certify a public key pgp -krs userid [keyring] remove selected signatures from a pubkey pgp -kd your_userid revoke your key & issue compromise certificate pgp -kd userid disable or reenable a key on your pubring ESOTERIC USAGES: pgp -d ciphertextfile decrypt message and leave its signature pgp -sb textfile [-u your_userid] create signature separate from textfile pgp -b ciphertextfile detach signature from a signed message OTHER FLAGS -a (ascii) produce ascii radix-64 output suitable for email -m (more) read in more mode, force reading in more mode -w (wipe) erase plaintext after encrypting -f (filter) input from stdin and output to stdout -t (text) when encrypting, treat input as ascii text -p when decrypting, recover original filename Ex: pgp -feast her_userid <inputfile >outputfile /* Jonathan Stigelman, Stig(a)netcom.com, PGP public key by finger */ /* fingerprint = 32 DF B9 19 AE 28 D1 7A A3 9D 0B 1A 33 13 4D 7F */

1 0

PGP question
by Nickey MacDonald 19 Jun '93

19 Jun '93

I am working on an interesting application using PGP.. and I have come upon a snag. I want to have a message with more that one "pgp block" ie more than one file encrypted and then all the encrypted files concatenated as one new file. If you just use "pgp file" it tries to overwrite the same file each time. If you give it multiple -o specifications, it only takes the last one, and tries to keep overwriting it. If you use -p, it names each file based on what the original encryptor called it, but in this application that would allow for the files to still overwrite each other. What I really need is a way to specify a "base" that is modified for each output. (eg base="file" and output files become "file.1" "file.2" "file.3" etc) Is this possible... can anyone give me *any* suggestions to improve the situation... This has to be an unattended operation. -- Nick MacDonald | NMD on IRC i6t4(a)jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger i6t4(a)unb.ca | (506) 457-1931 ^{1024/746EBB 1993/02/23}

2 1

Re: RRe: Blasting Bidzos Blather
by George A. Gleason 19 Jun '93

19 Jun '93

Consider also the possibility that Bidzos might have felt that it was either sell it now or have it seized later. National security seizures of crypto patents are nothing new. "He who turns and sells away, will live to sell another day..."

1 0

Re: Blasting Bidzos Blather
by Doug Porter 19 Jun '93

19 Jun '93

> NIST had no choice Pure bull puckey. First, they could have let DSA die. The commercial sector, particularly banks, would have come up with alternatives we could trust. Second, they could do what competent engineers have done for many decades: designed around inconvenient patents. Third, if they knew they weren't up to it, they could have asked for public help in that design. Fourth, they could have challenged PKP's patents on their merits. Fifth, they could have worked to get those patents declared void in the public interest. I personally don't support this one until PKP is shown to be primarily government controlled. They did none of these things. Why? Doug

1 0