- cypherpunks-legacy - lists.cpunks.org

Re: Are 2048-bit pgp keys really secure ?
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- One thing to keep in mind is that other things can go wrong than Carmichael-like numbers in finding false primes. You can get hardware errors. Here is my estimate of the chance of an undetected memory parity error. Let us suppose that a 8 MB PC uses parity protection per byte and gets one parity error per year of operation. This is just a guess but I have occasionally seen parity errors on PC's and I certainly don't use them full time 24 hours a day for a year! So the chance of a particular byte getting a parity error in a particular one-minute period (approximately the time for a key generation) is 1/(8M * 365 * 24 * 60) or about 2E-13 (2 times 10 to the minus 13). The chances of 2 parity errors, which would then be undetected, would be the square of this, or about 6E-26. During key generation let us just look at the data and say that there are about 256 bytes in the active working set at any time, so the chance of an error in an important byte is about 1.4E-23. So if your chance of the Fermat test failing is much less than about 10^-23 then you would do better to invest in a more expensive PC than in improving the test. And of course there are other hardware failure modes as well, which should increase this threshold. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLwGdahnMLJtOy9MBAQGolwIAzZFbwVx0pqLV3MgQrBYOWELISIsVgj5g BywmOcdqDZiqPAi+gTqR4C/zZQnHgLnnsxDH45OBcaVDHv8D4uSvjQ== =6YIb -----END PGP SIGNATURE-----

3 2

Re: properties of FV
by NSB's Portable (via RadioMail) 17 Dec '03

17 Dec '03

Once again, I've been on the road, and this time out of RadioMail range, so I'm a bit behind on my mail again. I hope that my replies aren't too redundant with other things that have already been said on the mailing list(s), but I can't check without delaying my answer even longer, because my poor RadioMail service is now so backlogged that it may take a few days just for it to download everything... At 11:17 AM 12/21/94 -0800, Eric Hughes wrote: >The perceived need for crypto "below the line" comes from the >viewpoint that the system needs to be completely secure because crypto >failures must be prevented at all cost. Rubbish. The subsequent >claim that you couldn't possibly put crypto on the Unix boxes which >are in your control is therefore also bogus. This is interesting; that was not the way I saw it, but I can see your point of view. From my end, I don't believe in "completely secure" as a reasonable goal for ANYthing, so this certainly wasn't what I intended to hold out for. Rather, my perspective is that if you add crypto, you should be getting something for it. It's easy to see how you get privacy benefits above the line, and if you do it right you might be able to get some security benefits too (though I haven't yet convinced myself of this). However, if we're going to be able to make some claims as to what we have added, I'd really like to be clear about them. What you've pointed out, that I hadn't thought of, is that if we put the crypto engine on the "above the line" system, we might get some significant and explainable benefits -- in particular, we gain protection of the user's privacy to the extent that breaking privacy now requires breaking into the above-the-line system, rather than merely snooping on the wire. This is true, and I thank you for pointing it out. I think I was a bit confused by the fact that I've thought of some really nice things that can be done when crypto is added BELOW the line, specifically related to the credit card information that ONLY lives there. What this means, however, is that there are now some useful things that can be done with crypto above the line, and even more that can be done with crypto below the line. If they were equally easy, it would make sense to add crypto below the line, as it would buy us more. However, as I've made very clear previously, it is NOT equally easy -- adding it above the line is much easier. This presents us with a new complication to the already complex tradeoffs involved in deciding where to devote our resources. I'm sure you'll understand if I'm reluctant to reach such an important decision overnight, but you've definitely opened my eyes to an attractive "middle path" in the use of optional cryptography in FV transactions. (On a technical level, the only thing I'd *really* like to wait for is the stabilization of the MIME-PGP work, as we'll need it in order to recognize a PGP-encrypted application/green-commerce MIME entity. As you know, I've been active in the MIME-PGP effort, and one very plausible scenario would be to make the FV server be an early implementation of that specification. However, the MIME-PGP draft that I co-wrote last summer is undergoing radical revision, so I'm reluctant to see that version implemented in our server.) In short, you've got a very good point, and you've probably just hastened the day when we support optional PGP encryption, but we're not ready to make any promises or timetables quite yet. >I really don't believe FV would have to put crypto on EDS equipment. "Have to" is the key phrase here. You're absolutely right, and you've pointed out that there's real value in putting crypto on *our* equipment. The attitude I had previously expressed might have been an example of "the best is the enemy of the good" which is something I try to avoid. On the other hand, there are undeniable advantages to putting crypto on EDS equipment -- it's an interesting tradeoff. >The message that it's "not necessary for commerce" is reactionary to >the assertation that it is necessary. By positioning FV in an >adversarial role with respect to cryptography, you'll have the same >problem no matter when you introduce crypto. I personally think >you'll have a harder time changing your position later, after more >people have been exposed to FV's current position. > >A much better public position is that "you can do commerce with or >without crypto", which asserts independence rather than negation. >These two public positions are _not_ identical; they are similar, but >don't be fooled by some positivist notion of denotation into thinking >that they're the same. This is another very important point. They may mean the same in some formal sense, which is what I believed, but your wording is MUCH more constructive. So let me state, with you, that I believe that you can do commerce with or without crypto, and that on the current Internet there are advantages and disadvantages to each approach. I suspect that we can further agree that privacy is one of the advantages of crypto-commerce, and that rapid deployment is one of the advantages of non-crypto-commerce. We may differ on some subtler aspects of that devil word, "security", but for the most part I think we're now in violent agreement. -- Nathaniel

1 0

Phil Zimmerman????
by dwomack＠runner.utsa.edu 17 Dec '03

17 Dec '03

I saw an earlier post discussing problems that Phil Zimmerman was facing. Is there any information about what those might be? Regards, Dave

1 0

re: Phil's plight *our fight*
by MWOHLER＠ix.netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Nick (The: prince(a)alpha.c2.org) aks: "If we don't take care of our own, who will?" I have made a pitifly small contribution to Phil Zee's LDF My first contribution to *any* cause on 20 years. C'mon c'punks this is where the ruber meets the road. Where are the fax distribution lists? Let's do it. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLwIQHmeikzgqLB7pAQFQ6gP/axPGNzgNMDmTPL4PeluIdZRYffhTfr4R BVOnUvXi13Eyob6C8Z+pPFDyAAl4IPDhoseU68dLpyL2jQ8vd7xTJU2FeLJYKhQV qgl7pWb1R/SB35kclRqMUmS0kMM/xRsmR7loLfhSTs9j2cG/1hO7DG3HkrHszfmQ N6rXVZIt8cU= =3wWQ -----END PGP SIGNATURE----- -- ***Preserve, Protect and Defend the private use of Strong Crypto*** * * * PGP for the masses * * * Finger mjwohler(a)netcom.com for Marc Wohler's public key fingerprint= F1 70 23 13 91 B5 10 63 0F CF 33 AD BE E6 7B B6

1 0

Re: Breaking into girlfriend's files
by arromdee＠blaze.cs.jhu.edu 17 Dec '03

17 Dec '03

Black Unicorn: >Person A requests information. >Person B says no, because the use of the information is unsound in person >B's view. >Censorship? You tell me. Not unless person B is trying to force other people not to give out the information. Failure to release the information himself is not censorship; it doesn't matter what his reasons for doing so are. -- Ken Arromdee (email: arromdee(a)jyusenkyou.cs.jhu.edu) "No boom today. Boom tomorrow, there's always a boom tomorrow." --Ivanova

1 0

Premier Rae of Ontario
by lmccarth＠freya.cs.umass.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A week or so ago I incorrectly referred to Bob Rae as the Prime Minister of Canada, when he is in fasct the Premier of the Province of v Ontario. As a former resident of OttOttawa, I'm well aware of the division of Canada into provinces. I misunderstood not the nature of the office itself, but rather the identity of the individual involved. I appreciate being corrected, but now I *have* been corrected, I really don't need any more mail about the issue. Thanks BTW this message is full of typos because I'm using a typically lousy terminal emulator program on dialup from a PC to a Unix system, which does not offer any support (AFAIK) for the crucially-important backspace key/ character. Suggestions on any sort of packasge offering an improvement would be welcomed. The ones I have now offer me heaps of fancy features I never use, and hold my hand through many parts where I don't need it. Incompatible standards sauck. This is very annoying so I'm getting out now. (Not signing because this connection is terrible) - -L. Futplex McCarthy - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLwKLzyoZzwIn1bdtAQEDwQGAje19PbaItVp7+fGPu7k/81IWixDxKsEE GKfVfoSKLxpLfGXv6cW2Vd9vSGIqXqxq =c1pZ -----END PGP SIGNATURE-----

1 0

HACK ATTACK
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Was I the only one who saw ``Hack Attack'' on the Discovery Channel? The promos were typically sensationalistic. `In cyber- space, there is no privacy.' `Teenage hackers can read, change or destroy your computer files.' `No one is safe.' Yada, yada, yada. Phyber Optik was interviewed in prison. A number of events were illustrated using `dramatic re-enactments.' Cop types told scary stories that, more often than not, ended with a statement like, ``The meltdown was caused by a programming error, but it could just have easily been done by a malicious teenage boy in his bedroom.'' They did do a fair job of defining and distinguishing the terms: `hacker,' `phreaker' and `cracker.' However, I don't recall ANY mention of encryption as a means of protecting privacy. Anyone else see it? S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

Re: HACK ATTACK
by Rich Salz 17 Dec '03

17 Dec '03

> in one of the re-enactment he states," I'm in! I control the > horizontal and the vertical..." It's a tag line from the old TV show The Outer Limits. /r$

1 0

rfcs 1750 & 1751
by Adam Shostack 17 Dec '03

17 Dec '03

FYI, RFCs 1750 & 1751 have been issued. 1750 discusses generating strong random numbers. 1751 standardizes a means of converting a 128 bit number to a set of English words. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume

1 0

RE: rfcs 1750 & 1751
by p.v.mcmahon.rea0803＠oasis.icl.co.uk 17 Dec '03

17 Dec '03

> FYI, RFCs 1750 & 1751 have been issued. 1750 discusses generating > strong random numbers. 1751 standardizes a means of converting a 128 ^^^^^^^^^^^^ > bit number to a set of English words. Both are informational, and don't represent standards of any kind - although RFC1750 has been subject to extensive review and scrutiny within the IETF security area. - pvm

1 0