August 1993 - cypherpunks-legacy

Re: ViaCrypt's PGP
by George A. Gleason 27 Aug '93

27 Aug '93

"No sir, we never used PGP" can probably be proven false if ViaCrypt has some kind of tweak built in. So then you get nailed both ways. No thanks; let's have someone check out the source code under NDA and then report back, and if ViaCrypt is clean, great, that can only help the overall cause. -gg

1 0

Commercial PGP; trapdoor rumors
by Mike Ingle 27 Aug '93

27 Aug '93

It would be very easy to put a trapdoor into a version of PGP, and the only way to detect it would be to reverse-engineer the object code. For example: take the date, recipient's key id, and a 16 bit random number, MD5 it, and that's your session key. They all look random, but to crack it you only have to try 65536 combinations (trivial - IDEA is fast). You could also set a trapdoor value which would always be accepted as a valid signature. However, it would be very unlikely that a company which deals in cryptography would actually do this. There are quite a few hackers around who can reverse-engineer code. If one of them found the tampering, ViaCrypt would be commercially ruined (magazine headlines, nobody buys crypto from them again) and likely open to lawsuits from anyone who ever used their product. If they really want to reassure us: let Phil Zimmerman and a couple of others examine *all* of the source code, let Zimmerman run the compiler himself, then Zimmerman and the others sign the object code and a statement that they certify the program has no trapdoors. Include this as a detached signature certificate with the program, much like PGPSIG.ASC. Also, offer a sizable reward ($1000 or better) for anyone who breaks either commercial or freeware PGP and tells how it's done. PGP uses randseed.bin and the time to generate random session keys. If you used the same randseed and wrote a tsr which freezes the clock (i.e. always gives the same value) wouldn't you get the same session key? You'd have to recopy randseed from a backup after each run, because it's re-scrambled. If you get free PGP to give the same key twice, commercial PGP should give the same key under the same conditions. There should be no way to tell, by looking at keys or ciphertext, whether they were created by commercial or free PGP. This would head off any persecution of free PGP users, provided of course that anyone who makes a cent from PGP had better *own* the commercial version. He could, of course, *use* the free version! Will PKP agree to condone the use of the free version for personal non-profit communication? They will if they know what's good for their bottom line. PGP could become a standard, and they stand to make a lot of money off its success. I hope that future U.S. PGP's are not hobbled with slow PKP-approved RSA code. If they are, I and many people will ftp the foreign versions from sites outside the U.S. > From: IN%"an31144(a)anon.penet.fi" 26-AUG-1993 19:17:39.96 > I would be pleased to see some truly exhaustive efforts made to test > PGP's actual security. > I have been seeing yet more criticisms of PGP, this time from some > character calling himself "Raymond Paquin." He claims to be a > professor of mathematics who has been working at an unnamed university > exclusively on cryptographics for the past twelve years. He implies > that he is working for some government in a classified capacity and is > thus unable to either publish or discuss the matter openly. > He claims that PGP is fatally flawed, though the flaw is in niether > RSA or IDEA, but rather somewhere within the PGP part of the program. > Copping the "I can say no more! I have said too much already!" > melodrama, no more detailed information is forthcoming. > Now, this tease seems to reek of a hoax, but Zimmermann himself claimed > no high degree of security for the program. To my knowledge, no serious > or well-funded unclassified attempts have been made to crack PGP. I > fear that we are putting our faith in snake oil, as Zimmermann puts it. > I am not a mathematician, but merely a former spear-carrier in the Cold > War with some fairly well-developed residual instincts about this sort > of thing, including a conviction that all security measures - physical, > electronic or cryptographic - can be compromised by a determined > opponent with extensive resources. Once compromised, attacks thereafter > may often be trivially accomplished. > From: IN%"an31185(a)anon.penet.fi" 26-AUG-1993 20:40:09.66 > an31144(a)anon.penet.fi writes: > ["Raymond Paquin"] > >.. claims that PGP is fatally flawed, though the flaw is in niether > >RSA or IDEA, but rather somewhere within the PGP part of the program. > > > >Copping the "I can say no more! I have said too much already!" > >melodrama, no more detailed information is forthcoming. > Yes, this seems to be a persistent rumour, though I've no idea how true > it might be. I uploaded PGP to a bulletin board a few months back and > received a message from another user claiming the same thing. (And taking > the same copout...) > I've been meaning to take a good look at the source for a while, I think > it's about time to investigate the key generation code..... Where did these rumors come from? 1: PKP 2: NSA 3: David Sternlight I remember a thread on alt.security.pgp about version 2.3 having a trapdoor in it. And I think they said the same about 2.2 before that. Whoever "Raymond Paquin" is, he's no spook. Spooks just don't do things like that - tell a little bit, then clam up. They are trained by instinct never to leak. Most rumors wilt under bright lights; where were these originally posted? Ask this person to post anonymously: where is the trapdoor? If there is any flaw in PGP, there are only a few places where it could be. The basic mechanics of the program (RSA, IDEA, etc) obviously work. The file format can easily be checked to make sure it is correct. A subtle flaw would have to be somewhere like: prime number generation, random RSA key generation, or random session key generation. If the primes weren't actually prime, that would make the RSA keys breakable. But you could take the primes (pgp -kg -l and you will see them in hex) and feed them into a primality tester to verify that. The most likely place for a bug would be in the randomness. I suppose it is possible that a one-line bug somewhere could leave out most of the randomness, making the keys still look random but actually be predictable. Random number generation is hard to verify. How has that in PGP been checked? The PGP source is so big and spread out, it's hard to check. I don't think there is a bug, but it would be nice if PGP were carefully examined and attacked. Where are these rumors coming from? They are bad for the cause. < mikeingle(a)delphi.com > PGP key on servers. Clipper - Big Brother Inside!

1 0

Digital Gold, a bearer instrument?
by hfinney＠shell.portal.com 27 Aug '93

27 Aug '93

][adon Nash's digital gold concept is interesting, however I think it is harder to use than existing cash systems in the literature. In order to know whether to accept a given piece of digital gold in payment for a product or service, a vendor must check a central database which records all transactions anywhere in the world. It must trace through the chain of possession for that piece of digital gold in order to verify that the ownership is legitimate. In particular, if the person passing the gold is a cheater he may be spending it twice, perhaps very close together in time. This means that the database must be updated and checked in real time. This is the same communications requirement for the simplest form of digital cash based on Chaum blinded signatures. We have discussed this cash several times on this list. It is basically just an RSA-signed certificate from a trusted bank, but one which has had the "blinding" technique (which Karl has been describing) applied so that the bank won't recognize the cash when it is returned. For a vendor to know whether to accept a digital coin, he has to check with the bank to make sure the coin hasn't been spent before. This is analogous to ][adon's check of the gold-claim database. The bank's job seems somewhat easier, as it just has to look up whether the coin's number is present in a list. Also, Chaum provides "offline" variants on his system in which the vendor just trusts the person passing the cash, because he knows that if the customer cheats, his anonymity will be automatically broken and he can be sued. It's not clear how the digital gold approach could provide any such generalization. As for the notion of transferring assets from person to person, using aliases to provide for privacy, this has been discussed by Barry Hayes in Anonymous One-Time Signatures and Flexible Untraceable Electronic Cash, in the AusCrypt proceedings. He describes a system, in some ways an elaboration of Chaum's ideas, which works like checks which get endorsed from person to person. Just the other day I got a check which was made out to person A but endorsed over to me. I could endorse it over to someone else if I want. This chain can continue until someone cashes it. Hayes's system, like Chaum's, retains anonymity as long as no one cheats. If someone tries to pass the same check twice, their identity will be revealed. It's too bad that these papers aren't more widely available. The math is not that complicated. If you can understand RSA, you can understand digital cash, at least the simpler systems. But the papers are mostly only in the crypto proceedings, and not all libraries have them. I have to say, though, that although I don't really think the digital gold proposal is technically feasible, the proposal to own numbers shows tremendous chutzpah and is quite creative. Hal Finney hfinney(a)shell.portal.com

1 0

Re: Viacrypt PGP source code unavailable
by hfinney＠shell.portal.com 27 Aug '93

27 Aug '93

I spoke briefly with Phil Zimmermann about the ViaCrypt deal this afternoon. He explained, as I understood it, that the company was contractually obligated to use their own version of the RSA library. This code is apparently proprietary and so the source is not currently planned to be released. Phil indicated, though, that he will discuss this issue with ViaCrypt, and hopefully some solution can be found which will satisfy users. It was not clear to me whether the random-number code from PGP would be retained. I suspect that it will be, though, which would mean that if you started with identical randseed.bin files, and RSA-encrypted identical files, that the two programs should produce identical output. PGP uses the contents of this file to initialize its random number generator. (PGP does put some random data at the beginning of the plaintext before encryption, as was described; this is to make cryptanalysis harder, since the first few bytes of the plaintext will not be known. Again, this random data is based on the contents of the randseed.bin file.) To address a few other points that were made: Phil reiterated his strong committment to keep the freeware version of PGP at least as up-to-date as the commercial version. This is not a case where the freeware version will be left to languish. In fact, Phil expects the commercial version to be based on the freeware version, with advances occuring first in the freeware code. As to whether individuals will pay $100 or more for a legal version, that remains to be seen. In some ways the same question can be asked about many commercial packages, for which pirated versions are available for free from friends or user groups. Yet still some people pay for software because they feel better using a legal version. People who feel this way would perhaps also prefer a legal version of PGP. Hal Finney hfinney(a)shell.portal.com

1 0

Attacks on remailers
by hfinney＠shell.portal.com 27 Aug '93

27 Aug '93

From: b44729(a)achilles.ctd.anl.gov (Samuel Pigg) > On the user side, I think a good tool to augment this would be a > mailer program which kept a list of the functioning remailers with > keys, and randomly selected a route through them using a random > (reasonable) number of hops, and performing the necessary nested > encryptions. Then it could start the remailer hopping process via > special socket connection to the first remailer in the chain. This seems like a good idea. Note that on the ftp site there are scripts and a program which will set up a chained remailing if you are willing to type in the names or numbers of the remailers to use. Extending these to use a random route or set of hops would not be a major job. > Perhaps a protocol could be worked out for the mailer program to > request from any one of the remailers a current list of the > functioning remailers? (in an effort to transparentize the process > some more, as manually maintaining a list of current remailers would > be tedious.) More and more I think this would be a good idea. People are always complaining about temporary "down time" among the remailers. Perhaps someone could run a service which would run every night, ping all the remailers, and keep a file with a list of those remailers which have responded in the last 24 hours. This file could be made available by finger, ftp, or some other method. Perhaps someone could volunteer to write such a beast? This is another project that seems doable in a moderate amount of time. Putting these two together, as Sam suggests, would produce a more robust and convenient way of using the remailers. Nice ideas, Sam. Hal Finney hfinney(a)shell.portal.com

1 0

Re: .Comparing ViaCrypt and freeware.
by bill＠twwells.com 27 Aug '93

27 Aug '93

If you're worried about backdoors, reverse engineer it and verify that it works as advertised. Given that the program has to largely duplicate an existing set of source, this should be trivial.

1 0

Apology
by cjl＠micro.med.cornell.edu 27 Aug '93

27 Aug '93

Sorry for the last post. It was sent to the board in error. cjl

1 0

viacrypt and freeware
by cjl＠micro.med.cornell.edu 27 Aug '93

27 Aug '93

>> As for why bother when the freeware is available, plausible deniability was >> mentioned and I think that is probably the most convincing argument. The >> Jackson Games seizure, and other computer confiscations by law enforcement >Note that the seizure had *nothing* to do with copyright or other IP >infringement; no incriminating material was ever found, and we were >completely cleared. Also, the name of the company is "Steve Jackson Games" >That aside, I agree with your basic analysis. It was not my intent to speak to the *specifics* of the Steve Jackson Games case, although your point is well taken. My reference was more to the point that as a reasonably well publicized event, particularly among the computer cognescenti, that people (i.e. sysops and owners) have every reason to fear completely outrageous and unconstitutional behavior from government agencies. The law enforcement agencies are well aware of the value of making a high profile example of how much they are able to get away with and be completely free from any redress of grievances. cjl

1 0

Cisco routers backdoor
by L. Detweiler 27 Aug '93

27 Aug '93

===cut=here=== Date: Wed, 25 Aug 1993 12:56:54 -0700 (PDT) From: Al Whaley <Al.Whaley(a)sunnyside.com> Subject: Cisco routers Rumors abound that Cisco routers have a back door; that is when a TCP port is disabled, it can still be accessed from Cisco's IP number. I have personally verified this with the sendmail port. Al Whaley al(a)sunnyside.com +1-415 322-5411(Tel), -6481 (Fax) Sunnyside Computing, Inc., PO Box 60, Palo Alto, CA 94302 [Private trapdoors for developers and maintenance folks are remarkably common, and in many other cases represent more serious risks than this one. WarGames was not pulling your leg. PGN] ------- End of Forwarded Message

1 0

Crypto Consulting / Employment Opportunities at Microsoft
by gnu 27 Aug '93

27 Aug '93

Posted at CRYPTO '93 in Santa Barbara this week were these two job offers, FYI: CRYPTOGRAPHER -- Advanced Technology and Business Development, Advanced Consumer Technology Group, reporting to Group Manager, Research Group Primary responsibilities include the research, analysis, verification, and recommendation of cryptographic methods; designing and proving new methods; and working with a development team to implement such methods. Candidate should be familiar with authentication techniques, blind signatures, digital signature and time-stamping techniques, public key encryption systems, hashing methods, and encryption standards. Familiarity with RSA, LUC, DES, minimum knowledge systems, and Digital Cash/Smart Card technology a plus. A MS/Phd degree in Mathematics, with a focus on cryptography, desired. Do you need a research challenge which results in tangable (sic) product? Then Microsoft is the place for you! Microsoft looking (sic) to challenge the brightest mathematical minds with the latest advances in cryptography. The ideal candidate will be responsible for the reserach, analysis, verification, and recommendation of cryptographic standards as well as the design of new standards. Candidate should be familiar with ... [repeats itself here] COMPUTER SECURITY EXPERT -- Advanced Technology and Business Development, Advanced Consumer Technology Group, reporting to Group Manager. Primary responsibilities include the reserach, analysis, verification, and recommendation of computer and communication security techniques; designing new methods; and working with a development team to implement such methods. Some programming responsibilities also will be assumed. Qualifications should include a minimum of 5 years experience with secure transaction systems, data security, authentication techniques, basic encryption technology, and knowledge of security standards. Famililarity with electronics funds transfer systems (SWIFT, ...), Smart Card technology, C/C++ language, and RSA encryption a plus. A BS/MS/Phd degree in Computer Science or related field preferred. Contact: Lester Waters, +1 206 936 4288, lesterw(a)microsoft.com Gideon Yuval, gideony(a)microsoft.com

1 0