December 2003 - cypherpunks-legacy

Re: fun with the web and security
by Bill Stewart 17 Dec '03

17 Dec '03

At 06:38 PM 2/27/96 -0800, you wrote: >Here's a fun way to exploit security holes via the web: > http://www.cs.berkeley.edu/~daw/js1.html >A rough representation of its contents follow. Well, that was amusing. (It gophered to localhost:25 and sent some mail and attempted to exploit a traditional sendmail bug.) I was wondering what would happen, since I'm behind a firewall and don't _have_ an SMTP listener on port 25, nor does my PC really do localhost in any useful manner. What happened, of course, was that Netscape used my proxy settings for gopher, sent the request to the firewall, and tried to connect to localhost:25 there; it answered, accepted some mail for delivery, then 503 Need MAIL before RCPT 503 Need MAIL command 500 Command unrecognized ... many of these 500 Command unrecognized 501 Syntax error in parameters scanning "root@localhost" 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 221 [MY PROXY MACHINE'S NAME]. closing connection Good stuff. (And I assume the proxy server had the debug hole blocked...) #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

Re: S/MIME outside the US?
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:49 PM 2/24/96 -0500, Lewis wrote: >volley(a)lls.se writes: >> If I got things right, DES is "exportable" as long as the keysize >> is kept under a certain size, which is too small to be really secure? > >All things are exportable as long as the keysize is kept under a certain size, >which is too small to be really secure. That's not correct - you can only export crypto code from the US for which you have Permission, and they'll only give you Permission if it's weak crypto or you agree to be Well-Behaved (e.g. US banks can export real DES for talking to other banks, but US banks can be subpoenaed and forced to hand over the plaintext.) There have been people who've gotten export permission for modified DES, e.g. real 56-bit DES with the key chosen from a 40-bit keyspace. I'm assuming from volley's address that he or she is in Sweden, and thus not directly limited by US export laws. Write what you want, and post it somewhere outside the US; we can import it legally. As a non-American, you probably couldn't get US export permission for even 40-bit RC4, and maybe not even for rot13. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

3 2

Re: Diffie-Hellman for Matchmaking?
by Bill Stewart 17 Dec '03

17 Dec '03

At 11:37 PM 2/27/96 +0000, Dimitris Tsapakidis <dimitrt(a)dcs.rhbnc.ac.uk> wrote: >This is a followup to my "Dating Problem" question [.....] What's the reason for ZKP below? Is the objective that A and B only know the other one is interested if they have also advertised interest, and that nobody else can tell they're interested in each other? Or just that you can advertise who you're interested in so that only they know you're interested and nobody else does (except possibly a Trusted Third Party.) For the latter case, instead of publishing g^(AB)mod n, publish hash(g^(AB)mod n), where hash is some non-invertible function (maybe strong like MD5, or maybe cheap like a CRC32, depending on how often you're willing to risk collisions.) If you're concerned about replay attacks, use something like (timestamp, MD5(timestamp, g^(AB)mod n)). >Person A is interested to match person B, so he computes >g^(AB)mod n. B is interested in X, where X may or may not >be A, and calculates g^(BX)mod n. Now, they compare these >two "common keys" either using some Zero Knowledge scheme >that ensures fairness (at no point one party has significantly >more information than the other) or through a Trusted Third Party. >If they are the same, then this means X=A, so A and B >have a match (e.g. a date). The common keys must remain >secret (hence the ZK above): if g^(BX)mod n "escaped" >to the public, then the real X would find out that >B is interested in him. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

Re: Simpler solutions (was Re: Stealth PGP work)
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:26 AM 2/28/96 -0500, Bruce Zambini wrote: >Or, you can develop a public-key stego system... >ie a stego system that uses bits in specific ways depending on the >private key of the recipient. I assume you mean the public key of the recipient? >Something I've been thinking about, but haven't quite figured out how to >do yet, except that one could use certain bits based on a PRNG and begin >the message with an RSA-encrypted seed (ie the first X bits will be the >seed, encrypted with your public PGP key). That's equivalent to stego(picture, ( RSA(sessionkey,pubkey), Symmetric(message, sessionkey))) where Symmetric is a potentially cheaper (and weaker) algorithm than IDEA that possibly uses transposition rather than strict block-structuring. This approach is no more obscure than stego(stealth(PGP(message, pubkey))) though slightly more obscure than stego(PGP(message, pubkey)), optionally less secure, and probably not much faster except for long messages with wimpy Symmetric. And it still suffers from the non-stealthiness of vanilla RSA that Hal Finney, Adam Back, Harry Hastur, and others have discussed. Might as well keep the stego and encryption parts separate. You gain a certain degree of obscurity by using stego(picture, scramble( PGP(message, pubkey), key )) where scramble is some cheap symmetric encryption algorithm and key is either the recipient's public key or keyid, and PGP is in binary mode. This hides the message from eavesdroppers who don't know the recipient, but not from eavesdroppers who are willing to test against the keys of a list of usual suspects (assuming the recipient is one of them.) #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

2 1

Re: Information... We need Information...
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 10:32 AM 2/29/96 -0800, Alan Olsen wrote: >Here is the problem... I am looking for texts on the breaking >of cyphers. (I want to show him WHY the cypher is insecure and >not just say "<scottish accent>It's crap!</Scottish accent>".) >I have done a couple of searches and have come up fairly dry. Some of Friedman's instruction manuals from the (pre?)WW2 days have been declassified. When I was down at Computer Literacy Bookshops (408/435-1118) in San Jose, they had 5 or 6 titles on codebreaking. Applied Cryptography talks about some more modern attacks, such as meet in the middle. Starting from the references and going to a good technical library might produce some information. Good Luck - Bill ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Re: Percy the Python loves IPG
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:41 PM 2/25/96 -0500, ab411(a)detroit.freenet.org (David R. Conrad) wrote: >I think the IPG system is great! Percy, my pet python, has never been >slicker or better lubricated! :-) >IPG Sales <ipgsales(a)cyberstation.net> wrote: >>Perhaps so, but our system does employ a true hardware generated OTP, and >>operates similiar to what you describe - however, the important >>differernce is that we use a small OTP to generate a larger OTP, like >>stringing the cable across the Golden Gate narrows. That's not a cryptographic one-time-pad - the folks who strung the cable across the Golden Gate used the little cable to haul a bigger hardware cable across - you're taking your little cable and stretching it into a longer thinner cable, tangling it up a bit, and hauling the ends across the narrows. You haven't added anything to it, so it hasn't gotten any stronger, and it may have gotten a lot weaker. If the Small Pad has S bits of entropy, and the Large Pad has L>S bits, the Large Pad still has s<=S bits of entropy in it, because you haven't added any more from your hardware RNG - you've just shuffled around the S bits of entropy you had and maybe even lost some if you're careless. Therefore, the Large Pad is not a One Time Pad, because it's using each bit of the Small Pad more than Once. Maybe you only use the Large Pad once, but it's no longer a One Time Pad; it's a small pad used more than once. By your own admission, you're using your pads more than once. A true One Time Pad has the property that each bit of pad has one bit of entropy, so even if I know the value of N-1 bits of the pad, I know entirely nothing about the value of the other bit, even with infinite computation. With your method, if I know N-1 bits of the large pad, and have a large enough computer, I can determine the other bit. Depending on how strong your algorithm for deriving the Large Pad from the Small Pad is, I may or may not be able to afford the computation, and the computer may or may not fit on one planet, but the bit is recoverable; finding a fast way to crack it is just gravy. Furthermore, there are two ways I can tell that you've only given the Large Pad to the two official recipients and destroyed your originals. One way is to totally observe your handling procedures all the time, so I know what you've done with it. This is obviously impractical. The other way, a bit less secure, is for you to sign a contract as part of your service that says what how you will generate and handle the keys, who you'll give them to, what bonding and insurance you have, and how much liability you'll accept for mishandling. This isn't mathematically secure, like a real one time pad, but it does establish a certain trust level - I now know how much care you're using with the pads, how much I can sue you for if you mess up, and therefore I can estimate the value of the information I can trust your product to carry. In general, that means I can trust it for conversations which have a specific, limited monetary value, such as purchase orders for parts - I can sue you for the $N I'd lose if the message gets stolen. But I'd better not trust it for high-value secrets, like my marketing strategy or trade secrets or plans to invade Cuba, because if you mess up, I can't recover enough money from you to cover my loss if they leak. So please email me the keys to your company; I'll donate 10% of the value to David's python Percy for extra snake oil. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

Re: A brief comparison of email encryption protocols
by cme＠cybercash.com 17 Dec '03

17 Dec '03

We're working on some of these issues, as we speak, over in the SPKI mailing list. Some of my contributions are available on http://www.clark.net/pub/cme/html/cert.html At 20:02 2/16/96, Laurence Lundblade wrote: >The Trust Model >--------------- >Any fully implemented system will have to choose some form of a trust >model. Some possibilities are: > * web of trust > * strict hierarchy > * web of hierarchies or some other hybrid The one some of us advocate is a web of certificates, each one of which assigns a specific attribute or permission to a public key. These certificates are not tied to human identities, but a human identity can be attached as yet another attribute of a public key via a certificate for that purpose. For many attributes to be attached to a public key [e.g., permission to spend money, permission to speak for an organization, ...] there is no need for a human identity beyond the implicit one of "the person who knows how to exercise the indicated private key" which comes with any public key. >The Certificate format >---------------------- >It seems possible to pick a certificate format independent of the other >issues. Doing so would allow us to leverage components like we do with >other data objects like MIME. There probably only two major contenders: > * X.509 v3 > + broadly supported by standard bodies > + supported by several industries (e.g., banking) > + very rich and flexible > + ASN.1 > - ASN.1 (tough for a student to get an ASN.1 compiler) > - complicated > * PGP keys > + widely deployed > + simple to write code for > - difficult to lookup (linear search on key id required) > - too simple to support many trust models and distribution systems We're proposing a third certificate format. X.509 is an identity certificate, unless one bends it severely. Signed PGP keys are also a kind of identity certificate. Our proposal is an attribute certificate, not an identity certificate. It is simple to lookup these certs. Like X.509, my certs have an Issuing-name and a Subject-name -- but they're both cryptographic hashes of public keys. You can take a portion of those hashes [e.g., low order 12 bits] and use it to index a hash table of certificates or keys. The cert is more general than X.509 -- that is, it includes all of X.509 and then some [because we don't require some binding to a human identity, don't require a Certificate Authority, ...]. Our first format is RFC822-like -- so it's easy to parse and generate and read and use. It's very rich and flexible. We're working to make it an IETF standard. It does not use ASN.1 and has none of the baroqueness of X.509. In fact, these certs can be formed as PGP clear-signed messages. > >Note that both use the RSA algorithms, so they are interchangeable at some >very basic level. We're using RSA or whatever else you want [e.g., DSA]. In fact, in our cert format, you can use DSA to sign an RSA key, a PGP key to sign a Fortezza key, etc. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc., Suite 430 http://www.cybercash.com/ | |2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | |Reston, VA 22091 Tel: (703) 620-4200 | +--------------------------------------------------------------------------+

2 1

Re: A brief comparison of email encryption protocols
by cme＠cybercash.com 17 Dec '03

17 Dec '03

At 12:01 2/29/96, Laurence Lundblade wrote: > >Isn't using a hash as the identifier replicating the key distribution >problem that PGP has or are you including some other data that can be used >to look up the cert? I think a problem occurs when you have 20 billion of >these certs (two for every person in the year 2010 or such). A simple hash >into a table isn't going to cut it because you a single database (with >replication?) isn't going to be possible. Some hierarchical lookup like >DNS is going to be needed. The look ups are needed to check for revocation. Our current straw-man http://www.clark.net/pub/cme/html/cert.html uses the following to identify a key within a certificate: KEY_ID ::= <hash of public key> [<nickname chosen by the owner>] [<URL of the full key>] It is assumed that the key is in a cache at the verifier. The verifier can add it to his cache by having it sent to him directly, by fetching it via the URL (if present), or through some other means. One of my co-workers [Donald Eastlake] is proposing distribution of keys via the DNS and that sounds fine, too. We weren't tying the distribution problem to the certificate problem. They really are separate. Revocation is a separate problem. My personal preference [quite seriously] is not to allow for revocation -- rather to issue certificates with a validity only long enough to get the job done but not so long that you'd be seriously damaged by having an invalid cert honored. There's no way to get 100%, immediate validation [by non-existence on a revocation list]. For more words on this subject, see cert.html. If one really needs CRL checking, I'd recommend including a URL for the Issuer's own revocation list as a field in the cert. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc., Suite 430 http://www.cybercash.com/ | |2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | |Reston, VA 22091 Tel: (703) 620-4200 | +--------------------------------------------------------------------------+

3 2

DC area physical Cypherpunks meeting this Saturday
by Pat Farrell 17 Dec '03

17 Dec '03

Starting at 3:00 PM, at Digex, as usual. Details on the Dccp homepage, http://www.isse.gmu.edu/~pfarrell/dccp/ (129.174.40.15 if the DNS is grumpy) Pat Pat Farrell grad student http://www.isse.gmu.edu/~pfarrell Infor. Systems and Software Engineering, George Mason University, Fairfax, VA PGP key available via WWW or request #include standard.disclaimer

1 0

Re: A brief comparison of email encryption protocols
by cme＠cybercash.com 17 Dec '03

17 Dec '03

At 12:01 2/29/96, Laurence Lundblade wrote: >I think a problem occurs when you have 20 billion of >these certs (two for every person in the year 2010 or such). A simple hash >into a table isn't going to cut it because you a single database (with >replication?) isn't going to be possible. BTW, at the rate that memory gets cheaper and smaller, it might be quite reasonable to have that single database fit alongside your daily appointments in your shirt-pocket daily organizer and e-mail terminal, in 2010. +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc., Suite 430 http://www.cybercash.com/ | |2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | |Reston, VA 22091 Tel: (703) 620-4200 | +--------------------------------------------------------------------------+

2 1