December 2003 - cypherpunks-legacy

Re: pgp library
by nobody＠jpunix.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Jim McCoy responds: > In addition to this, the code really sucks as far as modularity > goes. The next big version of PGP, which is supposed to include > library hooks, etc., will probably not be out for five or six > months. I do know of some people who are interested in working on > a PGP compatible library of crypto code, but I am not quite sure > what the status of that project is at this time... This is really a shame, because at the current time one of the most lacking aspects of most crypto software is the key management interface. Encrypting and decrypting pgp format messages is easily accomplished in an acceptable manner using the actual pgp binary. However, writing a decent key-management interface is practically impossible when your only interaction with the PGP key-management code is via the system() function call. Of course, shelling out to the PGP binary isn't the only solution. It's not impossible to create a simple library for encrypting and decrypting pgp format messages (there's PGPTools, and you can roll your own). But you are doubly screwed because the PGP development team has made it clear that the keyring file format will change in 3.0. Who wants to spend time writing a key management API (which, I admit, is NOT trivial...) which is guaranteed not to work in the next version of PGP? Why spend the effort to write a decent PGP front-end, which would necessarily include a key-management interface, when 1) Any effort expended in writing your own library or sprucing up PGPTools is supposedly being duplicated by the PGP team as we speak, and 2) your code is going to break anyway... ? PGP front-ends aren't the only application type whose progress is being slowed by this situation. IMHO, any app that uses PK-crypto should support PGPformat keys, even if it's output isn't designed to be fed into PGP. Don't get me wrong. I understand how difficult it is to do this and I am not ragging on the PGP developers for being slow or lazy or anything like that (I know they are underpaid). BUT, somebody must write a PGP library if we are to see major advancement in the penetration of crypto software into the mainstream. The question is, who is writing it? It almost seems as if PGP development is now happening in secret, and nobody really knows what the statusis on pgp 3.0 and the rumored library. There are people on this list who know, but nobody is telling. If the PGP people really are making progress on a PGP library, we need to know. We can probably help. If not, we also need to know so we can write one. Phase (yes you too can have a pseudonym) -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLu9kW5Ot8/1bCL+9AQGHaQP/dEaZ+3h/o8AB/gu0VLOjs14F8cgUwkm2 zpqgqFmh6Bna3GzANxSqf7R6Idmwp+y6hzk9YbDiItCE+r0inv9tp0pAE7JlPLg1 bWxM2Nd8r+ZpKhLExepNftJ9iiBewCtWNg9ylxs78VR3QjeKLBWlpcPODeIa2C0S kZlqVBwUBKY= =s1Nh -----END PGP SIGNATURE----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAy7vWyUAAAEEALwtONPeyYZ6jAYbFWgq8zTqttIclI/1wTjuFC3EkDzsjJM2 kkojkebMTwcJwLUgAL2+2EouAuM+MpyqAs+8/uMW42eP8kCS5XbLzSk5pisZpH/B kflaSeQ6lS6fr66nDHpR33wxQ+0lJWf94rJbaSWZGP2iN1W1jJOt8/1bCL+9AAUR tDlQaGFzZSBKaXR0ZXIgPGFsdC5zZWN1cml0eS5wZ3A+IG9yIDxjeXBoZXJwdW5r c0B0b2FkLmNvbT6JAJUDBRAu71tLk63z/VsIv70BAQkbA/9UUtJpfeTzi+OcNxQn QQEsP+xeusQWaJnS91sEYmjtzDJTqHOZ02Lh2tya0YZVl7ra8WJ6fbTzLR96s+vQ q+qYOwUUq+1OB6L4gdssK5ofRD/4M4dkWJlilY3eHI7Kch8KL/b2L1RG+r0rnEnG 6mH5XaHu7Lebf8wjtexJmKoWXQ== =mpBD -----END PGP PUBLIC KEY BLOCK-----

2 1

RE: A short primer on algebra
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >In the interest of good mathematical terminology, here is a short >primer on the most basic algebraic structures. The definitions are >not complete but rather evocative and are designed to prevent >confusion. Thanks...now if only I were able to go back to the cpunks meeting and listen to your presentation with this knowledge in hand :) ======================================================================= Johnathan Corgan "Violence is the last refuge of the incompetent" jcorgan(a)netcom.com -Isaac Asimov PGP Public Key: http://www-swiss.ai.mit.edu/~bal/pks-toplev.html Or send email to: pgp-public-keys(a)pgp.ai.mit.edu Subj: GET jcorgan ======================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLu9qJ01Diok8GKihAQGTvwP+Iy1yGbs/g0eVz6AJM/qQevYC6l5PVU7N 3XenXt7osO6gASd1NS6Pmfg2EQ/W3ArXgGY5TCL+1d7f6tBv5aUqqQg4Z1/ZJMln 8LAFVbDQIKkLbv/pz+1MqH8/DlEifQJAbNAiQBb/EC7S6J7EyrdIRAMNZy8reWWn AXadYEKOZH0= =EHV/ -----END PGP SIGNATURE-----

1 0

Re: Less Flaming, More Civility
by bshantz＠spry.com 17 Dec '03

17 Dec '03

On the subject of flaming... "It is beter to remain silent and be thought a fool than to speak up and remove all doubt." Can't remember who said it. -- Brad

1 0

Re: Clarification of my remarks about Netscape
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: kipp(a)warp.mcom.com (Kipp E.B. Hickman) > From the spec, the appendix on certificates: > > Certificates are validated using a few straightforward steps. First, > the signature on the certificate is checked and if invalid, the > certificate is invalid (either a transmission error or an attempted > forgery occurred). Next, the CertificateInfo::issuer field is verified > to be an issuer that the application trusts (using an unspecified > mechanism). The CertificateInfo::validity field is checked against the > current date and verified. > > Here is what we do in Netscape (for now). We have imbedded a set of > certificates in the client. The certificates are for issuers of > certificates that "we" trust. Any server which is certified by one of > these issuers will be automatically trusted by the Netscape > Navigator... > > Admittedly this is primitive, but it's a start. Thanks, I had overlooked that in the appendix. I notice you left off the next paragraph: Finally, the CertificateInfo::subject field is checked. This check is optional and depends on the level of trust required by the application using SSL. This subject field would hold the distinguished name of the server. That is pretty important to check! Otherwise anybody with any old certificate will fool you. In your appendix D when you describe the man in the middle attack, you say: The man in the middle operates by pretending to be the real server to the client. With SSL this attack is impossible because of the usage of server certificates. During the security connection handshake the server is required to provide a certificate that is signed by a certificate authority. Contained in the certificate is the server's public key as well as its name and the name of the certificate issuer. The client verifies the certificate by first checking the signature and then verifying that the name of the issuer is somebody that the client trusts. This is in accord with your description above. Note that the only name check mentioned is the name of the issuer. But later, in analyzing this attack, you say: If the certificate provided by the bad guy is legitimate, but for the bad guy instead of for the real server, then the signature will pass but the name check will fail Here you must mean a different name check, the optional one that checks the subject field. So this analysis is somewhat inconsistent with the procedure I quoted just above. Also, when you describe the subject name check as "optional" and depending on the required level of trust, perhaps you should say explicitly that if you don't do it you are vulnerable to a man in the middle attack. Actually, the attack is more general than that: if I could intercept connections to your server and use my own certificate to make the user think he is securely talking to you then I don't actually have to involve you at all. I am not a man in the middle, I am a spoofer pretending to be you. And you have marked the important step in the protocol which would check for this as optional. It appears from your docs that the Netscape client has a File menu item that brings up a Document Information dialog box which displays the distinguished names of the certificate issuer and of the subject (the owner of the key). This does provide a way of checking that you are securely connected to the server that you expect (assuming that the name is recognizable to the user). But it sounds like this is not something which the customer sees automatically. Again, this seems like an important security aspect which should be displayed more prominently. BTW, what do you see in the dialog when you connect securely to mcom.com? What is the subject name in your certificate? I hope these comments are helpful to you. I am surprised that you published this spec only after distributing implementations of it. This wil probably make it hard to change. Usually it is better to do the review before implementation rather than afterwards. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLu9zThnMLJtOy9MBAQEVPgH+KObAFiOsALCGokUzk7gsqpnVEda85MUD 5LU5P2GjFhmR5msBKr6uuDKSrodUl69bq0/CfpE3qYSzcz7SGPrrag== =ivlO -----END PGP SIGNATURE-----

1 1

Re: MIME (again)
by bshantz＠spry.com 17 Dec '03

17 Dec '03

>I'm using a version of ELM which claims to be MIME-compliant and usually is, >but all I saw in Peter Cassidy's message was a collection of random-looking >extended-ASCII characters. Usually when something arrives in a locally- >unsupported MIME format (like Amanda's GIF a while back), I just get an >"unrecognized format" error message. I didn't see any error messages at all >this time, just a meaningless jumble of characters (different, incidentally, >from the PGP-cipherptext-like characters Tim quoted). Hey, I've figured it out!!! It's the AOL Good Times virus!!! (**WINK**) We've all been had!!! Oh, sorry, I panicked. :-) -- Brad

1 0

Re: rad
by DBERLIN＠peddie.k12.nj.us 17 Dec '03

17 Dec '03

I wish the NSA executives would come out of the closet... That's nice

1 0

Re: Zimmermann Defense Fund Appeal
by nobody＠jpunix.com 17 Dec '03

17 Dec '03

On Wed, 14 Dec 1994, Hugh Miller wrote: > [...] > Phil deserves the best justice money can buy him. So this is the current state of your legal system. Oh dear.

5 4

Re: rad
by Ian Farquhar 17 Dec '03

17 Dec '03

On Dec 15, 8:45am, ndibble(a)komets.k12.cfa.org wrote: > I wish the NSA executives would come out of the closet... A couple of months ago there was some discussion of this on sci.crypt, as it is widely known that most the the TLA's do have Internet feeds nowadays. The main reason why noone from the NSA comments is simply because there is a perception that anything they say will be taken as NSA policy, disclaimers notwithstanding. Whether this would really happen is debatable, although my personal feeling is that it probably would. In an informational vacuum, people tend to jump to all sorts of conclusions based on inadequate evidence, and this situation would be no different. Ian.

2 1

Re: pgp lib
by shawn leas 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > Don't get me wrong. I understand how difficult it is to do this and I > am not ragging on the PGP developers for being slow or lazy or > anything like that (I know they are underpaid). BUT, somebody must > write a PGP library if we are to see major advancement in the > penetration of crypto software into the mainstream. The question is, > who is writing it? It almost seems as if PGP development is now > happening in secret, and nobody really knows what the statusis on pgp > 3.0 and the rumored library. There are people on this list who know, > but nobody is telling. If the PGP people really are making progress > on a PGP library, we need to know. We can probably help. If not, we > also need to know so we can write one. Here here! I agree. There are those who know, and to merely shut out all the expertise that might be on this mailing list is nonesense. I think the pgp library approach is very interesting. It could make pgp almost as common as winsock. We know that there is vast interest in finding a good front-end for pgp. The thing is, no one wants to dig around in code that utilizes poor modularity and try to flesh out an API. Once 3.0 comes out, one could build an app under windows using a PGP v2.x DLL, and a newly made PGP v3 DLL that would handle all kinds of keyfiles, a one step option to convert keyfiles, etc... I think the idea of writing a PGP DLL while the format will change in v3 of PGP is still feasable. Just use it again for backwards compatability. a PGWINP.EXE, a PGPV2.DLL, and a PGPV3.DLL. Or whatever. I've only had experience in UN*X, and maybe I'm oversimplifying everything. But, then again, what is ever simple when you have the trusty old 'windoze' GPF errors. I much preferr the unix 'segmentation fault (core dumped)'. Anyway, I will happily stand corrected on anything I say. Remember, just an idea! #include <stddisclaimer.h> #include <stdbroken_bsd_routine_defines_and_other_solaris_shortcomings.h> #include <stdbugs.h> #include <Niki_taylor.h> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLu99gCdA5IMp25vRAQFM7gf9Fmzx1ueMjuh9iORMQG03+33Z9DRUsL7W s8AFAQCHEwSSLgCNUZBQoRXhgb56c1z+Wvjhk6FvZTF6GyMqdF/8pkJTeQl2tHgo ayX61LDPqu7Xlx5tDyBblfJZ0kJJpF/SIpBe6dUIquSq5NxHodNcH8UmWNXzJ7LO 9fYl5/UJozyqLZHFPISNI/yIZtMJmFn1ogzIFagxrF4YxUVGe6+UAw+ZYfxiYYfb 8yVDdfmCkcjk3ksEcFtgmXs1ZJwAZ8B1IVeAWuJZSxSsO9Au6sO3q3rtFLEY3Vgu Ml45vI9gTJDlR0lwB0tAfx/R/VDfr2ji5Bra27ru69NUvt2zB54pMg== =Jx1p -----END PGP SIGNATURE-----

1 0

re: mime
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

> Probably because that is the direction mail is going. If you can't > do it too bad, but don't expect everyone else to wait around for you > to catch up. Time to move your mail into the early 90s and get a > MIME-aware mail agent... Ah, a refreshing sentiment ;) There is an EXCELLENT article in this month's Scientific American which touches upon this issue. "Ensuring the Longevity of Digital Documents". It mentions how a Shakespeare sonnet written four centuries ago is still readable. Data stored/formatted in completly cutting edge ways from a decade or two ago is in danger of becoming unreadable. (8" floppy disks, paper tape, CDC 876 mag tapes anybody?)

1 0