December 2003 - cypherpunks-legacy

Are 2048-bit pgp keys really secure ?
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A 2048-bit pgp key ( n=p*q somewhere around 2^2048, p and q somewhere around 2^1024) is only as secure as it looks like, if both p and q are prime numbers. In fact p and q are only pseudo prime numbers, they are not proven to be prime numbers. It is known only that they have a high probability to be prime numbers. Usually a candidate number is send through a probabilistic prime test which says either "No, not a prime" or "a prime with a probability of at least 50% ". Usually this test is repeated 10 or 20 times, so after passing this iteration the probability of having a prime number is at least 1:2^10 or 1:2^20 . Would such a test be sufficient for generating 1024-bit prime numbers? Does it make sense to use pseudo-prime-numbers with a low probability of 1:2^10 only to generate a rsa key with a 2048 bit n ? Now have a look at pgp2.6.2: In genprime.c the prime numbers are generated. After testing the candidates with a table of small primes, they are passed to slowtest(). [Read slowtest and its comment...] slowtest() does not do one of the usual primality tests. It just passes the candidate through a Fermat test. Only four (4!) passes are done. The comment of slowtest() gives a probability of 10^-44 to fail for a number of about 512 bit. If this is true ( 10^-44 ~ 2^-146 ), about one of 10^44 keys is weak. This shouldn't be a problem, 10^44 is quite big. But at the moment I can't follow the arguments, why 4 Fermat tests should be enough to find good (pseudo-)primes. I can't see a reason why the iteration should already be stopped after the 4th loop. Generating a key should be worth to wait some minutes longer, especially when this doesn't need interactive work. I am also not convinced yet of the Fermat test. Why not use a Rabin-Miller-Test ? I have read only a very small piece of the pgp code yet, but if I understand the code of slowtest well (correct me if not...) the command mp_init(x, primetable[i]) for i=0,1,2,3 sets mpi x to the values 2,3,5,7 . If I understood this well, the slowtest() is nothing more than testing for a given p whether 2^(p-1) = 1 mod p 3^(p-1) = 1 mod p 5^(p-1) = 1 mod p 7^(p-1) = 1 mod p Any comments? BTW: The comment of slowtest() references "Finding Four Million Large Random Primes", by Ronald Rivest, in Advancess in Cryptology: Proceedings of Crypto '91. I have the "Advances in Cryptology - Crypto '91, Proceedings", Lecture Notes in Computer Science, 576, Springer, here. Call me blind or stupid, but I can't find the referenced Article. Neither the Title in the contents, nor R. Rivest in the Author Index. Can anybody tell me where to find the referenced Article ? Hadmut Danisch BTW 2: pgp2.6.2 doesn't work well if a key identified by its keyid is keychecked ( pgp -kc 0x... ). It stops after the first signature with a signators key shorter than the signed/checked key, because the global precision is changed and not changed back for testing the signature. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLwBtzGc1jG5vDiNxAQHi6wP/WS3afYhQ0ijJZfWbByjtvPrCZtCfDs1M 1p8Paqx0ZIIgCE2G6tY8JTlZ6tn5nEY4/qGHS3Q3TrO77HVheKq2bHMajGzSA3At CoX65ycg2Pn30q7PeLY89vtNosW568CqnmpPAmusD+o9CFO6RpFFZxIb5pgY5brF 8ll/F1ztdmM= =JZS6 -----END PGP SIGNATURE-----

2 1

swIPe pointer please
by cjl 17 Dec '03

17 Dec '03

I need a pointer to swIPe info and preferably an FTP site. Responses to me by E-mail please. C. J. Leonard ( / "DNA is groovy" \ / - Watson & Crick <cjl(a)welchlink.welch.jhu.edu> / \ <-- major groove ( \ Finger for public key \ ) Strong-arm for secret key / <-- minor groove Thumb-screws for pass-phrase / )

2 1

Looking for PGE
by storm＠marlin.ssnet.com 17 Dec '03

17 Dec '03

Someone recently posted a list of steganography files. I've managed to l\o\s\e\secure that information and can't f\i\n\d\access it. Does anyone have a pointer to PGE (Pretty Good Envelop) or a recomendation for another program for MSDos? Thanks! -- America - a country so rich and so strong we can reward the lazy and punish the productive and still survive (so far) Don Melvin storm(a)ssnet.com finger for PGP key.

1 0

Re: Making sure a program gets to the receiver intact
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Eric writes: > From: an169306(a)anon.penet.fi > How can I insure a program, once put on FTP sites stays untampered with? > > The best solution is not digital signatures but rather digital > timestamping. The question is not persistence of authorship but > rather persistence through time. > [Discussion of the implications of getting your keys hacked, over time] Some good points, but on the whole I'll disagree. Either way, the solution pretty much comes down to "eternal vigilance".... The interesting technique that digital timestamping provides is that it lets you show that the version you claim you posted to the ftp site got there before the [different] version that's there now. To use that technique, either you need to broadcast the details of the digital timestamping in an unhackable public fashion, or else someone who wants to validate the archived data needs to check with you to be sure that they have a good checksum matching your timestamp. An ftp server *could* timestamp each incoming document, keeping the master timestamp data in an un-hackable location, and post the current timestamps for the current time period [e.g. day] in the (hackable) archive, and then register the day's timestamp file with a notary service so you can be sure that the file hasn't been compromised later. On the other hand, without signatures, it's not too hard for a Bad Guy to store bogus files on the server and get them timestamped too - the user needs a good way to check for previous editions of the document in the timestamp file. With digital signatures, at least a given file has some internal consistency. > The holes: > 1: Someone hacking the keyservers, substituting a key for all the people > who signed, and modifing the archive to show that. That's why keyservers are inherently non-trustable; the trust comes from the Web of Trust connections you have, though a keyserver run by a widely-trusted person carrying only keys signed by him/her/it is stronger. > 2: Someone breaking into my apt, sticking a keyboard monitor on, getting > my passphrase and key. Yup. That's a problem with signatures. Bill

6 6

This list and a question
by camp＠industrial.com 17 Dec '03

17 Dec '03

I just joined this list last week, I may have been greviously mistaken, but I thought that this list talked about technical issues of being a cypherpunk. It seems to me that most of the things posted here belong is a newsgroup rather than in my mailbox. So I guess the question is: Is there a cypherpunk newsgroup, and if there isn't why? I am not complaining so much about the content, but I get so many mail messages about things that I would just as soon miss in my mail box that I have a hard time finding the messages that I do want. Just a thought. . . . Hey and is there some sort of FAQ? gemnis

1 0

Why I have a 512 bit PGP key
by Matt Blaze 17 Dec '03

17 Dec '03

[Speaking of dumb things: when I added my PGP key to the bottom of this file a few minutes ago, I attached it to the pre-proofread version and sent that instead of this one. Sigh. Here's the correct version.] A while back, I generated a PGP key pair for use on my machine at work, a Sun SparcStation sitting on the reasonably-well-protected- from-outside-attack AT&T internal research network. I selected a key length of 512 bits. My number theory friends tell me that this is weak by modern standards; cracking my key would probably require within an order of magnitude of the total computational effort expended in the recent attack on RSA-129. I even volunteered my key as a ``target'' for the next such attack. Still, I'm happy with my choice, or rather, I've got so many other security things to worry about that compromise of my private mail based on cryptanalysis of my dinky little public key to obtain my private key is the last thing on my mind. In fact, I kind of like it that my key doesn't advertise pretensions of high theoretical security when, in fact, there is very little at all in practice. The first problem, of course, is secret storage. Modern networked computers are awful at storing secrets. (This, after all, is one of the problems that crypto software like PGP aims to solve). I suspect my situation is reasonably typical, if not better than most. My computer at work sits on my desk (in my locked office), has its own local disk, only I know the root password, I try to keep up with the latest security patches, and I keep most of my files in encrypted form under CFS. I'm the only regular user of my workstation, and while I'm at work I access it directly from the console. The network to which it is attached is AT&T's ``R&D Internet'', the same one that sits behind the firewall described in Cheswick and Bellovin's great new book. I probably have at least average system administration and general computer security skills, and I'm reasonably good about practicing what I preach. Sounds like a pretty secure machine from which to run PGP, right? I don't think so. While my machine's operating system is pretty self-sufficient, my own home directory sits on a remote file server administered by people who are good at and have time to perform essential services for me like taking backups. This means that, no matter how hard I try, it's impossible for me to be sure that none of my files have been tampered with. We use off-the-shelf NFS, which means that for all practical purposes anyone with access inside the firewall (that's about 50k people in my case) can replace any of my files. Furthermore, even though my office has a lock, I'm not the only person in the world with the key (Bell Labs escrows office keys, after all), and I've managed to pick the lock once or twice on days when I left my key at home. I really have no idea where my machine has been or what software I'm typing at when I run PGP. So where should I store my private key? Well, I could, as some have suggested, keep it on a floppy disk that I carry around with me everywhere I go, but first of all, that's too inconvenient. It also sounds dangerous in practice. A floppy disk is about the size of a US passport, and I've already lost two of those. That means I'd have to replicate the key somehow anyway, so I might as well rely on the reasonably well established backup procedure that protects me from loss of the rest of the files in my home directory. For all practical purposes, I have to assume that my secret key file is public. That leaves the passphrase to protect the secret key. According to Shannon, English text contains just over 1 bit per letter of real information. Even if we assume twice that to account for the added twists and turns of phrase I'm inclined to add to a passphrase, I just can't remember (or type) a phrase with anywhere near enough entropy to approach the level needed to do justice to even a little 512 bit RSA key. I think the simplest cryptanalytic attack against me would be to go after the passphrase-based encryption of the secret key file. (You'd need a way to enumerate the most likely keys based on a hashed passphrase, which is a problem not yet well studied in the unclassified literature. I suspect a solution is not out of reach of a determined adversary, however). An even simpler attack would be to break in to my machine and replace my copy of PGP (or my kernel, or my shell, or whatever) with one that records the passphrase as I type it. (No, I don't leave this as an exercise to the reader!) The next problem is with PGP itself. While I haven't looked carefully, it seems to be a well-engineered program, and it has a number of design features that I admire. However, I think the basic model it implements sits at too high a level, making it inherently unreliable for really sensitive traffic. It's just too hard to use. (Most of the problems could be fixed by pushing things to a lower level, and I understand a number of people are working on this). In particular, I'm forced to have too much involvement in each PGP operation, and it's just too easy for me to do stupid things like: - encrypting messages with the wrong public key - sending the cleartext file instead of the ciphertext file - leaving the cleartext file around in an unprotected file system - including the passphrase in the message (especially when your fingers are so used to typing it all the time...) - forgetting to use PGP at all - typing a passphrase over a network connection (especially easy when you've got several windows open on several machines). Systems that use hardware keys (smartcards, etc) are less vulnerable to this I've done each of these dumb things at least once, and probably others as well. Don't get me wrong - I advocate the use of strong encryption as much as the next nerd. I'm just concerned about focusing so narrowly that we lose sight of the larger security picture. Perry Metzger once made reference to cryptographic "size queens" who worry about key size and nothing else - it's a phrase that rings true. There's something to be said for systems that offer security parameters that provide about the same strength across various attacks. DES is a good example - a 128 bit key DES could be designed that is at least as secure as the current 56 bit version - by at least few bits. The engineering triumph is that the "advertised" DES security parameter - the key size - tells close to the truth about the overall security of the system. (Of course, in RSA-based systems, there's an added variable - advances in factoring - that may make it prudent to include a significant margin for error, especially for keys that must retain their strength over time). I have a 1024 bit key at home. -matt -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.1 mQBNAitm4zgAAAECANYaL7K5Ca5B4Sq3udKKkFasQNrgfKGoWRUjwB/10lAFVrhN aKz/b6iJXFxZ6g+YlCvdQTu/EUO6JkBihshIRgEABRG0D21hYkBiaWcuYXR0LmNv bbQhbWF0dCBibGF6ZSA8bWFiQHJlc2VhcmNoLmF0dC5jb20+iQCVAgUQLIG7Ga1S SlGFGX+1AQEt7QQAtwhDbN/799e763LrbhB5ItoR1r2ud+nWBZi0S64OVnVkLjnd zVwMouPiaiEs/ORWQfoVPmME6fMYlUeh+uLonSDymjzosWyU6yJRs8lcAy2MMBR+ De00mHk8+nDAuY0j4udH2oqvd6V6IEgsN8bQeme8CkNj3uULmzNMrYtns7aJAJUC BRAr3LtEs25wSZyVhQ8BAXQwA/wIxBaxEM/DER96N6o00qzzJog8nbKGH2S4achc P0/96N9FXgnnoKybARfG+ZfliuuMRyt40MIkg1/Z5PzLg0m5dVzXgkYv7B98bI+8 dVuzENJRzBbbmSDemcTaF2KWdtW7U66xFSP6S86RDOuQHzg6uCi2tmoJhvdWroWz VVxGj4kAlQIFECtzeqp9h9s63RlgUQEB8UoD/ilKx2sUFzQwkM3DSRQZun5FoR1N ujmt710NHkn3BFcRcBAU1o6VEHg0MlQXYEDk16YnhUEZDy0QuMrxXWcLee1UP2jl k0+ezNP5NMsSMt7HVjGJ+xi+exc6+Clyl/WjSEhpears1kBWAI12eVbO1uI/uGr5 vksZqkPoT8a1WaumiQCNAgUQK21uiULwpfyXKdSbAQFErAO/TsSmabCpT4Uzi/zQ 14yBiDqwatj8mhaE60nG8wiqQv4W4hmDXjrxGRr0LQNM3eBLCkoEpKIDmL1RuwtB Z4AUsqoJTC2Yq46KnSznfqgY0F+C4kSptxo0p1KJ79FKFlW9dyTKVBB1WOBzbsw1 Kx/oog+DmUH0VIbYiQCVAgUQK21W3FTdX6I8ZiRnAQHErAP+P+WalKGRrgM/v8pp o4YKYmXxjsLUx89WJXMkxkoSzB7/ny7ITHo9i42qR+aXlsa+gqxdwRDrpI6k9FFF AhZ8s/bdZKpnXOJOjaj4P5LRbYem2VOZ8e9omXhHfz7a7NRUTimLA/q6lphy3Ulp byrua5Q8BkzQzI3RgbKEPshuOjeJAJUCBRArZuU6hr7UV33/hTMBATvGA/42wy/x BEVb5bOQiFTpEuB80Df53zt+b4TmfeueMMiDvvj7A5joLk7X/7x6HaBxHN/thbd6 S9NncWJfvy/PMnsQEmKarn45kwn/2xxDu2Po7pUN6Uj9DyA9uY+ilzqfk7ZA3RwH cbZA0Qv6LDNbapJXgFANwOC1tRB6yLtSG3T0iw== =V30c -----END PGP PUBLIC KEY BLOCK-----

7 13

Re: Making sure a program gets to the receiver intact
by snyderra＠dunx1.ocs.drexel.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 12:30 PM 12/28/94, Ian Farquhar wrote: >The ftpd's that implement the directory-change messages is not a standard >one, and that functionality has been added to the servers which support it >(possibly Linux ships with wuftpd, but no commercial version of Unix I know >does.) The extended servers are very widely available, and although they >do make ftp so much nicer to administer, they are not as widely deployed as I >would have expected by now. BSD/OS, from BSDI, ships with wuarchive's ftpd. Most sites offering any serious quantity of files have a new ftpd, like wuarchive's. Bob -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLwDYL+S0CjsjWS0VAQEOKAP9FXIfEaM2/cF5VPPXIA+Nko/3zdCbWot8 Nl9WjSjnpV2vaKnUYkhVUF7fslMaDBAjk24fvSj7eSjjY4YOxHmWRaJ1X189iZpz pCA4aXh/KXZDQhRQnfe/MojmqBLhAaFwYrC17Pq90Ab/WSNPLZ6ahTpKKEwf/fEA iK4ronPRz14= =rRwk -----END PGP SIGNATURE----- -- Bob Snyder N2KGO MIME, PGP, RIPEM mail accepted snyderra(a)post.drexel.edu PGP & RIPEM keys on key servers When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

1 0

Phil's Plight
by prince＠alpha.c2.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Well fellow Cypherpunks, I am amazed and shocked. One of our own, Phil Zimmermann is in deep shit and it's about to get deeper. As of this date I have seen very little discussion on how we can help him out. The thing that shocks me the most, is that Phil and the PGP development team have laid the basis for a lot of the Cypherpunk tools we take for granted. And still with all of the distractions and worries that he currently has, he's working on new tools, that I'm sure we will use and implement in various projects. I think Phil deserves better than the silence his plight has received as of late. I know if we put our collective heads together, we can come up with many ways to help him out. Organized fund raisers might be a good way to start, or perhaps a fax campaign to make the media and legislators aware of his situation. The possibilities abound. If we don't take care of our own, who will? This post might start a flame war. If it does, I do not apologize. At least the topic is being discussed. Nick -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLwDgklr3MzuHJu11AQHSdQf/ZgiuWOonZC/VI7BqmVV5iKMTbqe3FzP0 6TUa7GzEU+rnBSBUQCGBZjKFtuBeW3WlRp1va+TEdhJY4RlhJf919cKHJN0F4h8f HgvlAl227OuOfZ6nhneM23hrKbbas7YnuSbcxNmGsTXK/s7Fk19nrsvvEpM/eFmZ ocNL2J57MGJpRuos0+anZavqwEFB01qt5eakDEKnx9BFStsgOAjB/U5lnDOAjHZM /w7hTgZ/A6xCCnOaBICqWmmZfdaNQlcTqYLriPryFPG9C34MQ5MDr3mJMTSmPIgR NcDESOs4ncaMszEB5C5TnufJFH5aM1SQjXOQH/BzrH87/eKsyElOQA== =AX7D -----END PGP SIGNATURE-----

1 0

Pointers for www pages, please
by cjl 17 Dec '03

17 Dec '03

I'm looking for crypto/security/cypherpunk URL's obviously ftp.csua.berkeley.edu http://www.c2.org What's the proper URL for Vince Cates web-page? Other suggestions to me by E-mail please, My purpose for this is mostly to be able to point people I run into on the WWW towards info on C-punk issues and warez d00D :-) Cypherpunk antonym/homonym of the day awareness not equal a-wareness (a state of not having software . . . .) C. J. Leonard ( / "DNA is groovy" \ / - Watson & Crick <cjl(a)welchlink.welch.jhu.edu> / \ <-- major groove ( \ Finger for public key \ ) Strong-arm for secret key / <-- minor groove Thumb-screws for pass-phrase / )

1 0

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