- cypherpunks-legacy@lists.ogf.org

Re: Coming Soon: Commercial version of PGP!
by dmandl＠lehman.com 27 Aug '93

27 Aug '93

> gg(a)well.sf.ca.us writes: > > > How soon before a Mac compatible version is available? Or will the > > current version run under Soft PC on the Mac, which is essentially a > > PC-emulator...? If yes to either, sign me up...! > > Have you tried the freeware version of MacPGP yet? It is very easy to use. > The next release (now in beta) will even support AppleEvents. I think it will > be quite a while before you can buy something similar. > [And why would you want to pay if you can get for free?] > > --Marc I was a beta tester of the latest version of MacPGP, and it looks *very* nice. Some annoying minor bugs have been fixed and a few new features added, including a hook for BBEdit (a godsend). I assume it'll be released any week now, if not sooner. If it's true that the freeware version of PGP will be allowed to exist alongside the new (sourceless) commercial version, I don't think the cypherpunk in the know will have much trouble choosing... --Dave.

1 0

Re: Source Code NOT available for ViaCrypt PGP
by George A. Gleason 27 Aug '93

27 Aug '93

"(the problem is) convincing ViaCrypt to trust (some Cypherpunk)." There are cypherpunks who have sufficient assets that they would reasonably be considered to want to protect themselves from losing same in a lawsuit over violating the terms of the non-disclosure agreement. Hey, if you have equity in a house, you begin to qualify for this one. Better if you own a company or have other significant assets. If someone here stands up and says, "Hey ViaCrypt, I'll put my (house/company/stock portfolio/etc.) on the block to back up my NDA, now let's play ball," ViaCrypt will have a very very hard time saying no. And if they do say no, they come out looking very bad indeed. If ViaCrypt are reasonable people, let's give them the reassurance that any reasonable person needs against the possibility of getting burned. Then the ball's in their court, and they've got to respond. -gg

1 0

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

27 Aug '93

Source code for ViaCrypt: I believe I raised a point about having some trusted members of the crypto community (i.e. cypherpunks) examine the source under non-disclosure. Well...? This is an entirely reasonable demand. There are people in this list who are highly placed professionally, who own companies that are worth a reasonable sum, or who own houses at least, and therefore who can be trusted by ViaCrypt to not blow the gig because the resulting lawsuit would cost them mightily. So we trust those folks because they're part of this community, and ViaCrypt would trust them to not blow their NDA because they could be sued all to hell. Also from ViaCrypt's perspective, think of the marketing value of having the product independently certified or validated. That would certainly be worth something. NOw if Viacrypt refuses to go with this, that fact in and of itself would be harmful to their position: it would be a virtual admission that their system was dirty. The question is, who here wants to take this on...? To me the point is very straightforward: we have an interest in privacy, and the legal issues around privacy... the fight to preserve "underground" crypto fits into this picture, but I can't see any justification for boycotting or trying to tear down ViaCrypt simply because they're charging a fee for it and are making a profit on it and all that. Free markets, right? A successful ViaCrypt product would probably spread around to many users who would never have gotten onboard with PGP, for instance businesses who want to be totally squeaky clean about the copyright issues. We need everyone onboard who we can get, and we *don't* need some kind of PC litmus test of "are you willing to use underground software?" -gg

1 0

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