Re: Making One-time pad using the soundcard
David Honig wrote: [I would not feel particularly comfortable merely combining the bits of a single sample -- distilling entropy using a hash function and large blocks of input would probably work out better. I'm sure there will be plenty of opinions around here. --Perry] A secure hash will only obscure entropy measurement (a good hash gives 1bit/symbol *apparent* entropy even if only few input bits change infrequently). You must measure your distillate's entropy before hashing if you hash. The purpose of the secure hash is to make sure your entropy is evenly spread. Clearly you must measure it before this whitening (though I'm underconvinced you can actually measure entropy in real life - however, I'm certain you can't after its been whitened). Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: What's Wrong With Content Protection
John Gilmore wrote: Few or no manufacturers are willing to put ordinary digital audio recorders on the market -- you see lots of MP3 *players* but where are the stereo MP3 *recorders*? They've been chilled into nonexistence by the threat of lawsuits. The ones that claim to record, record only "voice quality monaural". Which is ironic, because there's any amount of free software out there that will do it. We don't need their steenkin' MP3 recorders. :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: NONSTOP Crypto Query
Ray Dillinger wrote: On Fri, 12 Jan 2001, John Young wrote: Wright also describes the use of supersensitive microphones to pick up the daily setting of rotors on cryptomachines of the time, in particular the Hagelins made by CryptoAG. Hmmm. That sounds like a trick that could be brought up to date. If you get two sensitive microphones in a room, you should be able to do interferometry to get the exact locations on a keyboard of keystrokes from the sound of someone typing. I guess three would be better, but with some reasonable assumptions about keys being coplanar or on a surface of known curvature, two would do it. Interesting possibilities. Bear [A quick contemplation of the wavelength of the sounds in question would put an end to that speculation I suspect. --Perry] Hmm. 6 kHz has a wavelength of 5 cm. I would guess you can easily get resolution to 1/10 of a wavelength under ideal conditions. Which is .5 cm, which is half the size of a key, more or less. Sounds pretty feasible to me. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Fwd: from Edupage, December 22, 2000
Jaap-Henk Hoepman wrote: On Tue, 02 Jan 2001 12:03:40 -0800 David Honig [EMAIL PROTECTED] writes: At 10:27 PM 1/1/01 +0530, Udhay Shankar N wrote: Did this slip between the cracks in holiday season or has it already been discussed here ? Udhay Its just yet another 'secure' scheme that uses quantum theory (here, discrete photons; elsewhere, entangled photons) to detect or prevent leaking bits. More elegant than gas-pressurized, pressure-monitored 'secure' cables, but the same idea. Except that eavesdropping on the quantum key distribution channel is _always_ detected (by `laws of nature'), which is not true for these pressure-monitored cables. I thought that detection in quantum systems was probabilistic? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Cryptographic Algorithm Metrics
John Young wrote: Last summer, at a workshop on "Security Metrics," conducted by NIST's Computer System Security and Privacy Advisory Board, Landgrave Smith, Institute of Defense Analysis, reported on a pilot study of "the metrics used for determining the strength of cryptography." http://csrc.nist.gov/csspab/june13-15/sec-metrics.html (the workshop) http://csrc.nist.gov/csspab/june13-15/Smith.pdf (Smith's presentation) Five catergories of algorithm strength were established for the pilot: Unconditionally Secure (US) Computationally Secure (CS) Conditionally Computationally Secure (CCS) Weak (W) Very Weak (VW) Smith stated: "A cipher is Unconditionally Secure (US) if no matter how much ciphertext is intercepted, there is not enough information in the ciphertext to determine the plaintext uniquely." No examples for this strength were given, and it was not clear from Smith's presentation whether there is such a cipher or the category was only provided as a theoretical premise. Question: is there a cipher that is Unconditionally Secure? One-time pads. A cipher is Computationally Secure (CS) if it cannot be broken by systematic analysis with available resources in a short enough time to permit exploitation. Examples: DES and 3 DES. Wrong, DES is Weak. A cipher is Conditionally Computationally Secure (CCS) if the cipher could be implemented with keys that are not quite "long enough" or with not quite "enough" rounds to warrant a CS rating. Examples: SKIPJACK and RSA. A Weak (W) cipher can be broken by a brute force attack in an acceptable length of time with an "affordable" investment in cryptanalytic resources (24 hours and $200K). No examples. A Very Weak (VW) cipher is one that can be broken by determining the key systematically in a short period of time with a small investment (8 hours and $20K). No examples. An example of this would be the cipher used on DVDs, or the mobile phone one, both of whose names I've forgotten. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Cryptographic Algorithm Metrics
Greg Rose wrote: At 03:06 PM 1/3/2001 -0500, John Young wrote: Yes, the one-time pad. However, I wondered if Smith was hinting at another cipher(s) not yet publicized, perhaps computational -- or more exotic technology such as quantum, DNA, ultra-spectral and beyond. It always amazes me that people single out the OTP here. There are any number of other algorithms that are unconditionally secure. The simplest is Shamir's secret sharing, when you don't have enough shares. At Crypto a couple of years ago the invited lecture gave some very general results about unconditionally secure ciphers... unfortunately I can't remember exactly who gave the lecture, but I think it might have been Oded Goldreich... forgive me if I'm wrong. The important result, though, was that you need truly random input to the algorithm in an amount equal to the stuff being protected, or you cannot have unconditional security. The OTP is just the simplest realisation of this. Don't you think that's a pretty good reason for singling it out? Is there any additional merit in the more complex realisations? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Cryptographic Algorithm Metrics
Peter Fairbrother wrote: At Crypto a couple of years ago the invited lecture gave some very general results about unconditionally secure ciphers... unfortunately I can't remember exactly who gave the lecture, but I think it might have been Oded Goldreich... forgive me if I'm wrong. The important result, though, was that you need truly random input to the algorithm in an amount equal to the stuff being protected, or you cannot have unconditional security. Not so. Perfect compression with encryption works too. You can argue (reasonably, IMO) that the stuff being protected is the entropy in the stuff you first thought of, which can be no bigger than the compressed data. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: IBM press release - encryption and authentication
David Wagner wrote: Enzo Michelangeli wrote: OpenPGP tries to detect such "wrong key" situations for symmetrically-encrypted packets in a pretty simplistic way, [...] The repetition of 16 bits in the 80 bits of random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. This does not provide message integrity or message authentication. It provides a much weaker property: If you've decrypted with the wrong key, this will let you detect that fact. Padding also does that, of course. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Security Against Compelled Disclosure
People may be interested in a paper Ian Brown and I wrote, with the above title, for ACSAC. http://www.apache-ssl.org/disclosure.pdf Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Is PGP broken?
"L. Sassaman" wrote: PGP will also never have the platform coverage that open source software can have. In addition to all the platforms (except Macintosh) that PGP supports, GnuPG runs on Irix, True64, FreeBSD, NetBSD, OpenBSD, BSD/OS, SCO, SunOS, and others. That's not PGP's fault; it's just the nature of commercial vs. open source software. But to say that PGP runs on "nearly all platforms" is misleading. ??? I have PGP running on FreeBSD. Did I miss something? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Is PGP broken?
Russell Nelson wrote: Is it just me, or is PGP broken? I don't mean any particular version of PGP -- I mean the fact that there are multiple versions of PGP which generate incompatible cryptography. Half the time when someone sends me a PGP-encrypted message, I can't decrypt it. Presuming that I'm right, is anyone attempting to fix PGP? Not to mention anything about PGP keyservers, or the utter and complete absence of anybody doing point-source PGP signing. Although it is broken the strategy I use is to use a 2.x generated key with 5/6.x PGP versions. This seems to work pretty smoothly. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Republic targeted for sale of 'unhackable' system
William Knowles wrote: The system may run foul of the Regulation of Investigatory Powers Bill (RIP) in Britain, which, if passed, would insist that security services should be able to decrypt communications networks to preserve national security. This part is _definitely_ snakeoil - RIP makes no such requirement. But it sure sounds good on your marketing material, right? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
REMINDER: UK Crypto meet at ApacheCon
As I mentioned a while back, I'm organising a meeting for anyone interested in crypto in the UK during ApacheCon. I've finally managed to schedule it, and its happening on Tuesday the 24th of October at 15:00 to 16:00, in the "large BOF room" at ApacheCon. Info on ApacheCon can be found at http://apachecon.com// (the short version is that its at the Olympia Conference Centre). BOFs are open to anyone, so there's no requirement to register, but you may care to register for an expo ticket just for fun. The agenda: that's up to you, but one thing I would like to discuss is whether there is sufficient interest to have regular UK crypto meets, and where/how often to have them. Sorry for the short notice. It would be nice if people who are coming would let me know so I can estimate numbers (if there aren't enough to justify the large room, it would be polite to switch to the smaller one). If anyone wants to put stuff on the agenda, mail me. Cheers, Ben. -- http://www.apache-ssl.org/ben.html ApacheCon Europe 2000 is next week, Oct 23-25: http://apachecon.com/
Re: [Fwd: [ANNOUNCE] NSS 3.1 Beta 1 Release]
William Allen Simpson wrote: -BEGIN PGP SIGNED MESSAGE- I remember you expressing such sentiments on the mozilla security list some months ago. But, there are problems with the OpenSSL license. As far as I can tell, the problems are invented rather than real. At least I can't recall any real problems except "it isn't the licence we want it to be". And not enough crossplatform support. Gasp! What do you mean? Can you name a platform it doesn't run on? And, I'm a big believer in multiple independent implementations. Of free software? That's silly. To clarify: there may be a reason to have other implementations to _test_ the "real" one, but there's no point in duplicating the massive amount of work that has gone into optimising and porting OpenSSL. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: [Fwd: [ANNOUNCE] NSS 3.1 Beta 1 Release]
William Allen Simpson wrote: -BEGIN PGP SIGNED MESSAGE- Ben Laurie wrote: As far as I can tell, the problems are invented rather than real. At least I can't recall any real problems except "it isn't the licence we want it to be". I was not aware that OpenSSL had changed to be compatible with GPL. And I cannot find the license statement on the web pages. The licence has not changed. Specific concerns from email were: From: [EMAIL PROTECTED] (Tim Hudson) BTW the SSLeay license was not derived from the Apache license, but actually from the original BSD licensing terms with some changes added to prevent problems that had occured with previously released software being adopted into other licensing schemes and other people claiming authorship of software they did not write. I wrote the SSLeay license to go with the first public release of the SSLeay code so I think that my understanding of the origin of the license can probably be accepted as accurate :-) I don't see any concerns here, just a history lesson. From: Frank Hecker [EMAIL PROTECTED] I think getting rid of the advertising requirement in the OpenSSL license needs to be done anyway, to eliminate potential problems with using OpenSSL code in other projects where the GPL is used. However note that making the change is not as simple as it sounds, because in order to change the OpenSSL license you'll have to get permission from all the OpenSSL contributors. And this, as far as I can work out, is really just saying "it isn't the licence we want". There is no requirement in GPL for the OpenSSL licence (or any other) to not have an advertising requirement, again, as far as I can work out - where does it say that? Gasp! What do you mean? Can you name a platform it doesn't run on? For example, I'm writing this on MacOS. Although there was a single reference to MacOS buried on the web pages, it doesn't appear to be ready for prime time. The current beta has MacOS support. Of free software? That's silly. To clarify: there may be a reason to have other implementations to _test_ the "real" one, but there's no point in duplicating the massive amount of work that has gone into optimising and porting OpenSSL. I firmly disagree. For example, the first several implementations of IPSec and Photuris were "free", made in different countries and under different licenses. This continues to be very important to this day. It often takes a considerable length of time for minor problems to surface -- note the recent discovery of buffer overflow issues in RSAref 5 years after it had been widely used. Heterogeneity is of the utmost importance in maintaining a passibly secure infrastructure during a time of repair. Here you may have a point, though given complete lack of compatibility at the API level, I'm not sure how this point can apply to OpenSSL and NSS. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: [Fwd: [ANNOUNCE] NSS 3.1 Beta 1 Release]
William Allen Simpson wrote: Fallout from the early RSA release into public domain, the references to BSAFE have been replaced, and a bunch of stuff are GPL. Is there a team of folks doing independent code review? Since this is likely to show up on a lot of systems, and any bugs will plague us for a long time, this seems to me to be a time for serious cooperation. What they _should_ do is use OpenSSL and work on that, instead of reinventing the wheel. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
[Fwd: [Freesw] [Fwd: software patents in Europe]]
Sorry about the mess of cross-forwarding! Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ If the information is correct (which I am not in a position to confirm), you should say YEP and not GAK. It seems unlikely that the EPO can obtain agreement in the coming diplomatic conference on a text that would be opposed by Germany, the UK and France. Additional precision: from what I understand, this would have been a vote in the board of EPO, on which text would be proposed for revision of the European Patent Convention at the Conference. The original proposal of the Director of EPO was for straight removal of art. 52 paragraphs (2)to(4), that is exclusions to patentability, based on argumentation that the requirements of inventive step, industrial applications, etc, were sufficient. I do not know if this is the proposal that was discussed in the board. Philippe Gak!!! -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ - - - Forwarded Message - - - Internet: [EMAIL PROTECTED] Authorised by: Internet: [EMAIL PROTECTED] Freeform name: Steve Bellovin Message ID:2913125531.E57D435DC2(a)smb.research.att.com To:Internet: [EMAIL PROTECTED] Subject: software patents in Europe (Not strictly on-topic, but nevertheless of likely interest to many readers of this list.) According to the (online) Wall Street Journal, the board of administration of the European Patents Office has voted to permit software patents, by a 10-9 vote. Opposition to the change came from the Germans, the French, and the British; smaller countries, such as Switzerland, Liechtenstein, and Cyprus, supported it. A German official is quoted as saying "We would have problems with the U.S. tendency to patent everything that can be patented. That would stifle innovation and cause a glut of litigation." A final decision will be made in November. --Steve Bellovin - - - End of Forwarded Message - - - ___ Freesw mailing list [EMAIL PROTECTED] http://mail.conecta.it/mailman/listinfo/freesw
Re: More thoughts on Man in the Middle attacks and PGP
"Arnold G. Reinhold" wrote: At 10:15 PM +0100 9/12/2000, Ben Laurie wrote: "Arnold G. Reinhold" wrote: I had some more thoughts on the question of Man in the Middle attacks on PGP. A lot has changed on the Internet since 1991 when PGP was first released. (That was the year when the World Wide Web was introduced as well.) Many of these changes significantly reduce the practicality of an MITM attack: 1. The widespread availability of SSL. SSL might be anathema to the PGP community since it depends on a CA model for trust distribution, but it has become ubiquitous and every personal computer sold these days includes an SSL enabled browsers and a set of certs. If Bob fears he is under MITM attack, he can use SSL to tunnel out. Several companies, such as hushmail.com, are already using SSL to offer secure e-mail services. These can be used directly by Bob to ask people at random to verify the version of Bob's public key at the various PGP key servers. An even better approach would be to use SSL to secure connections to PGP key servers in different parts of the world. This would force an MITM to subvert all the key servers as a minimum. There's really nothing stopping an implementation of SSL that uses PGP for key verification. All that's really required at the end of the day is some ASCII (to check the server name) and a public key, verified according to the requirements of the, err, verifier. Allowing SSL to accept PGP keys might be handy in other contexts, but not here. If Bob wants to rule out a MITM attack and he somehow has an active PGP key (other than his own) that he trusts, he can simply send PGP-encrypted mail asking that key holder to verify Bob's public key at the key servers. The value of SSL in this context is that every PC comes with a set of certs that can be used to validate an SSL link. (Mine came with 66 certs) Bob can walk into any computer store and buy a PC or a Windows disk off the shelf. Unless the MITM attacker has access to the private portion of these keys (perhaps a risk if your expected threat is United Spooks of Earth), and is willing to risk that compromise being exposed, his electronic bubble is pierced. I was addressing "SSL might be anathema to the PGP community since it depends on a CA model for trust distribution". Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: More thoughts on Man in the Middle attacks and PGP
"Arnold G. Reinhold" wrote: I had some more thoughts on the question of Man in the Middle attacks on PGP. A lot has changed on the Internet since 1991 when PGP was first released. (That was the year when the World Wide Web was introduced as well.) Many of these changes significantly reduce the practicality of an MITM attack: 1. The widespread availability of SSL. SSL might be anathema to the PGP community since it depends on a CA model for trust distribution, but it has become ubiquitous and every personal computer sold these days includes an SSL enabled browsers and a set of certs. If Bob fears he is under MITM attack, he can use SSL to tunnel out. Several companies, such as hushmail.com, are already using SSL to offer secure e-mail services. These can be used directly by Bob to ask people at random to verify the version of Bob's public key at the various PGP key servers. An even better approach would be to use SSL to secure connections to PGP key servers in different parts of the world. This would force an MITM to subvert all the key servers as a minimum. There's really nothing stopping an implementation of SSL that uses PGP for key verification. All that's really required at the end of the day is some ASCII (to check the server name) and a public key, verified according to the requirements of the, err, verifier. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
UK Crypto Meet
I intend to arrange a short Cypher/Coderpunks-style meeting in London during ApacheCon, which is 23-25th October at the Olympia Conference Centre. The main purpose of the meeting will be to discuss whether we should have real crypto meetings in the London area, and how/where/when to do that. If anyone plans to come, then let me know (I'll need to know numbers so I can book a room). If anyone cares which day/time, let me know. If anyone wants to talk about anything in particular, let me know. If no-one plans to come, I'll give up on the idea, so do tell me if you are up for it! Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: reflecting on PGP, keyservers, and the Web of Trust
Ray Dillinger wrote: On Tue, 5 Sep 2000, David Honig wrote: The more hard-core distribute keys to previously known parties on physical media, only. I have long felt that PGP missed a trick when it didn't have automatic expiry for keys -- It should be possible to build into each key an expiration date, fixed at the time of its creation. For shorter keys, it ought to default to expiring sooner, and not allow expiry more than a year or two out. For a 2048 bit key, it ought to default to something like 10 years and let you pick a term up to a century. This would solve one of the biggest problems -- old keys that should long since have expired but which go right on getting used. ftp://ftp.ietf.org/internet-drafts/draft-brown-pgp-pfs-01.txt Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: reflecting on PGP, keyservers, and the Web of Trust
Dave Del Torto wrote: At 11:14 pm -0400 2000-09-01, Russell Nelson wrote: Ed Gerck writes: Even though the web-of-trust seems to be a pretty good part of PGP, IMO it is actually it's Achilles heel. Nope. Usability is its Achilles heel. PGP needs to be wrapped in something, and yet it's not really designed to be wrapped. Even if it were, PGP, Inc. changed the interface! Doh! And then there's the whole encryption method problem. No, web-of-trust as a problem is way down there on the list. Actually, you're both right (or wrong, if you prefer you glass half-empty ;) it's the poor tools for key management of other people's public keys that is the Achillies heel, especially since the integration with seriously kick-ass keyservers is still not there. Of course, that's also a UI problem, but if you solve it, the ciphersuites (key types) "encryption method" problem lbasically goes away. Transparent key management, guys. Everything is a key management problem from now on. I'd be amazed if this is true - I manage vast numbers of files with seriously crap tools - I can't believe I need hugely better tools to manage the relatively small number of public keys I have to deal with. I suspect you only think this because you have to deal with the keyservers more intimately than most of us do. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
[Fwd: A note to the public - relayed from Ralf Senderek]
-- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ -BEGIN PGP SIGNED MESSAGE- A note to the public. I have been warning repeatedly to use newer versions of PGP for over two years now. In a study I put on the net in August 1998 which is also present on the PGP-International website I expressed my valuation of the ADK-problem which came with the newer versions. May I cite one sentence from my earlier work: "I do not know which mechanism will prevent a user's public key to be linked with another faked message recovery key without the user's consent or knowledge." I expressed my fear that this can happen and hoped that there will be security-checking mechanisms to prevent this. But not knowing much about the details of signatures and packages in 1998 I finally started to put this to a test because in the meantime almost everyone got used to the new keys. Completing my study and making sure that everyone who repeats my tests will get the same results I presented my study to the public on Tuesday 22nd August 2000 and informed persons working on computer security immediately. So I did not find a bug in the PGP-source code, that was Steve Early working with Ross Anderson after having studied my experimental research at Cambridge on Wednesday. I discovered that there simply is no checking done, not even the attempt to detect unauthorized manipulations of public keys. This is not a bug, this is a scandal, because NAI put ADKs into PGP without caring about simple manipulations. Obviously there has never been a well thought-out security strategy and most of the relevant information the public got from NAI concerning ADKs was completely untrue as my experiments reveal. No quick debugging will solve this situation and the damage being done to the reputation of PGP by everyone who supports Additional Decryption Keys. I am opposed to Additional Decryption Keys, as you know, but I do not want people to turn away from PGP. I would like to see people getting rid of the ADK-problem actively by checking the keys they use and avoiding the new signature type. "Use PGP-classic in a reliably secure environment." That would be my advice if I had 49 characters left on the telegram. Ralf Senderek -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBOae3cimc/oJTgiNJAQFsQAP+L+KfUcsDBkM3oGjSPEs/L1I04WGfhPjH lRzqJYsNEN69A6K72eg1x8zHkeKGfIGQlS2eC9QbE4ZX4GTblh3Kdc8GXzCHRMSi O2i1U765L7/0HbwKPSpyHZXMu96T0UpXSxJN61YqgKMr3zpreyySHBHWCCMLOjLv sSqoFUCBnaw= =8nRq -END PGP SIGNATURE- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.* * Ralf Senderek [EMAIL PROTECTED] * What is privacy * * http://senderek.de* without * * Tel.: 02432-3960Sandstr. 60 D-41849 Wassenberg * PGP-2.6.3i? * *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
[Fwd: Serious bug in PGP - versions 5 and 6]
-- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ Ralf Senderek has found a horrendous bug in PGP versions 5 and 6. It's of scientific interest because it spectacularly confirms a prediction made by a number of us in the paper on `The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption' http://www.cdt.org/crypto/risks98/ that key escrow would make it much more difficult than people thought to build secure systems. He's written a paper on his work and it's at http://senderek.de/security/key-experiments.html Since NAI joined the Key Recovery Alliance, PGP has supported "Additional Decryption Keys" which can be added to a public key. The sender will then encrypt the session key to these as well as to your main public key. The bug is that some versions of PGP respond to ADK subpackets in the non-signed part of the public key data structure. The effect is that GCHQ can create a tampered version of your PGP public key containing a public key whose corresponding private key is also known to themselves, and circulate it. People who encrypt traffic to you will encrypt it to them too. The problem won't go away until all vulnerable versions of PGP are retired, since it's the sender who is responsible for encrypting to the ADKs, not the recipient. In the meantime there might be a nasty denial-of-service attack in which bad guys upload tampered versions of everybody's public keys to all the public keyrings. Ross PS: my student Steve Early has trawled the PGP-6.5.1i-beta2 source code and found the bug: In file libs/pgpcdk/priv/keys/keys/pgpRngPub.c, I see two functions: one called ringKeyFindSubpacket(), which finds a subpacket from a self-signature packet, and ringKeyAdditionalRecipientRequestKey(), which uses ringKeyFindSubpacket() to search for ADK subpackets. ringKeyFindSubpacket() is declared as follows: PGPByte const * ringKeyFindSubpacket (RingObject *obj, RingSet const *set, int subpacktype, unsigned nth, PGPSize *plen, int *pcritical, int *phashed, PGPUInt32 *pcreation, unsigned *pmatches, PGPError *error); In particular, the "phashed" parameter is used to return whether the subpacket was in the hashed region. Now, looking at the call in ringKeyAdditionalRecipientRequestKey() I see this: krpdata = ringKeyFindSubpacket (obj, set, SIGSUB_KEY_ADDITIONAL_RECIPIENT_REQUEST, nth, krdatalen, critical, NULL, NULL, matches, error); ...the "phashed" value isn't checked (or even asked for)! Fixing the bug, and generating BIG WARNINGS when ADKs are found in the non-hashed area, should be trivial.
Re: Comcast@Home bans VPNs
Russell Nelson wrote: Ian Brown writes: ... subscribers to agree not to use the service as a means to create a VPN. Could someone describe to me (in my ignorance) the problem this rule is intended to solve? Loss of revenue from leased lines. BT did a number of interesting things during their ADSL trial to prevent the same problem, culminating with configuring the routers to block incoming connects (so you can't run servers on ADSL). One thing they overlooked was that the routers are in the customers' premises, leading to widepsread router hacking. This led to a rather amusing email reminding triallists that hacking their router was in breach of the TCs! They also reduced the bandwidth available considerably once they realised that, strangely, people hadn't subscribed to ADSL to watch postage-stamp-sized versions of crap movies served directly on the ADSL backbone, and really just wanted faster Internet access (I used to love the survey calls I got during the trial - BT: "So, sir, which movies have you watched from our multimedia server?" ... me: "What multimedia server?", and so on). Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: names to say in late september
Eric Murray wrote: On Thu, Jul 27, 2000 at 07:05:38AM -0700, Rodney Thayer wrote: What shall we call that-public-key-algorithm-that-will-not-be-patent-protected in late September? we should not use a trademarked or copyrighted term, in my opinion. There was discussion of this a while ago, I think. I don't recall what was around. I suggest "Rivest Public Key", or 'RPKey'. Too close to "RPK". It's not the prettiest buzzword I've ever suggested, but is there something better to call it? "The algorithm formerly known as RSA"? That is, TAFKA, which is _so close_ to Kafka I don't know how anyone can resist! In Singh's "Code Book", he relates a story where Aldeman insisted to Rivest that his (Aldeman's) name be last on the paper... Ron had originally had it in alphabetically order. Perhaps "ASR" might then be appropriate? Errr ... if you get the order right, you might see why he didn't want it... Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: FBI announcement on email search 'Carnivore'
David Honig wrote: At 10:58 AM 7/12/00 -0400, Steven M. Bellovin wrote: There's been speculation about NSA black boxes in such facilities for years. The FBI, however, isn't quite as "above the law" as the NSA likes For $500/monthly you too can have a box in various NAPs. You can run your NIC in Bill Clinton mode, e.g., to measure certain things about traffic. I know of a corporation doing this (they are only interested in infrastructure traffic, not content). Dunno about you, but we use switches for colo - which rather defeats this plan, no? Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: Java, Crypto and Speed
Peter Wayner wrote: Has anyone experimented with writing crypto code in Java using the BigInteger class? It's a nice package with plenty of neat functions, but I haven't played with it yet. Is it fast enough? I'm really curious about the speed. Lucre uses BigInteger (currently). It is fast enough for Lucre. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Extracting Entropy?
OK, so if I've got a passphrase of arbitrary length, and I wish to condense it to make a key of length n bits (n 160), what's the approved method(s) of doing that? I assume it goes without saying that we wish to preserve as much entropy as we can, but I'll say it anyway. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: Extracting Entropy?
Matt Blaze wrote: I should point out that this construction is not designed to obscure the input from the output (especially under differential probing), only to give you m output bits that depend (each in a different way) on the entire input. Perhaps I should add that as a requirement. OTOH, assuming H is perfect, wouldn't that make this construction resistant? But I assume you are reluctant to attempt to prove that. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: outlook certs
Markku-Juhani Saarinen wrote: [EMAIL PROTECTED] wrote: Recently on Polish conference about network security one person from the audience has showed me something which I don't quite understand. The following is commented record of my shell session with a certificate generated with MS Outlook 97 certificate manager, the same results were obtained with MS Exchange Key Manager. My first guess is that openssl does not work correctly when the length is not divisible by eight. Does this certificate actually *work* ? It shouldn't be a problem to have odd-sized moduli. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: MS Outlook certs
Pawe³ Krawczyk wrote: Hello, Recently on Polish conference about network security one person from the audience has showed me something which I don't quite understand. The following is commented record of my shell session with a certificate generated with MS Outlook 97 certificate manager, the same results were obtained with MS Exchange Key Manager. I have received the certificate with email and saved it to file kurs10.cer, which is PEM certificate. First I dump its contents: bash-2.03$ /usr/bin/openssl x509 -in kurs10.cer -text -noout Certificate: Data: Version: 1 (0x0) Serial Number: 932714537 (0x37981829) Signature Algorithm: md5WithRSA Issuer: C=PL, O=oi-wbd Validity Not Before: Jun 13 09:54:03 2000 Not After : Dec 14 09:54:03 2001 Subject: CN=kurs10, CN=recipients, OU=oi-wbd, O=oi-wbd Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (510 bit) Modulus (510 bit): 20:55:5f:0b:f3:5c:7a:c1:96:bd:36:72:53:c0:ed: a8:b5:24:af:34:d9:c0:66:1f:56:dd:ee:99:32:e1: 6a:63:cb:10:43:99:7b:20:1c:08:c3:9d:09:4f:82: df:01:76:c4:ad:7b:90:22:de:1f:66:3e:78:5e:1c: 01:e4:eb:3d Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSA 85:30:cd:a1:30:19:95:42:f7:c7:1d:f8:1b:bf:0e:c6:2f:f5: 80:05:ed:04:07:3c:34:96:c8:04:60:3a:a3:33:90:65:c9:50: 27:c1:4f:73:16:63:c8:ab:e6:91:71:4a:7a:09:88:e0:ad:3a: 2a:84:f9:43:0f:bf:ef:2d:46:1c Why are there only 510 bits of the key? Presumably they don't ensure that the top bit is set, so there's a 1 in 4 (ish) chance that the first two bits are zero. Another key I've tried, generated with MS Exchange KM was 511 bits long. Anyway, I then extract the modulus: bash-2.03$ /usr/bin/openssl x509 -inform PEM -in kurs10.cer -modulus -noout Modulus=20555F0BF35C7AC196BD367253C0EDA8B524AF34D9C0661F56DDEE9932E16A63CB104399 7B201C08C39D094F82DF0176C4AD7B9022DE1F663E785E1C01E4EB3D And try to factorize it with `factorize' program from GMP-3.0.1 library: bash-2.03$ ./factorize 0x20555F0BF35C7AC196BD367253C0EDA8B524AF34D9C0661F56DDEE9932E16A63CB1043997B201C08C39D094F82DF0176C4AD7B9022DE1F663E785E1C01E4EB3D 3 5 57241 210729581 12383993^C After finding a few first components (3 5 ...) the program is still working and I've stopped it. Shouldn't the modulus consist only of two primes? It should! Could anyone explain what's wrong either with my methodology or with the certificate? It was generated by MS? Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Beginners books on security
I was asked to recommend boks on security/crypto/copy protection for the non-tekky and realised I had no idea at all! Does anyone out there have suggestions? Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Lucre - with extra blinding!
Lucre has been updated to add the much-discussed double-blinding. So far, only the TeX and Java have been done - C++ will follow ... comments welcome! http://anoncvs.aldigital.co.uk/lucre/ Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: NSA back doors in encryption products
John Gilmore wrote: Anybody tested the primes in major products lately? Interesting point ... of course, these days one can produce checkable certificates of primality - but I'm not aware of any free software to do it ... is there any? Is it time for the Campaign for Real Primes[1]? Cheers, Ben. [1] Apologies if this quip dies in translation! :-) -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: NSA back doors in encryption products
Enzo Michelangeli wrote: - Original Message - From: Ben Laurie [EMAIL PROTECTED] To: John Gilmore [EMAIL PROTECTED] Cc: Rick Smith [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 24, 2000 9:08 PM Subject: Re: NSA back doors in encryption products John Gilmore wrote: Anybody tested the primes in major products lately? Interesting point ... of course, these days one can produce checkable certificates of primality - but I'm not aware of any free software to do it ... is there any? What about the one quoted below? Errr... CERTIFIX is an executable for Win95, Win98, NT (hardware Intel compatible). 'nuff said! Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: RSA admit that actually free software is quite good...
Ben Laurie wrote: http://www.asa.org.uk/adj/adj_4765.htm I've been asked to explain what this is ... the ASA is a UK body, the Advertising Standards Authority. Their brief is to ensure that advertisements are legal, decent, honest and truthful. The URL referred to above is an adjudication against RSA Security Inc., upholding a complaint that RSA had untruthfully described free software as unsupported and out-of-date. Cheers, Ben. -- http://www.apache-ssl.org/ben.html
RSA admit that actually free software is quite good...
http://www.asa.org.uk/adj/adj_4765.htm Cheers, Ben. -- http://www.apache-ssl.org/ben.html
Re: SSLeay.Org Still A Trusted Source?
"Scot E. Wilcoxon" wrote: As I was updating my security skills this week, I found that the ssleay.org domain has become lost. Someone registered it a few weeks ago and it now only contains banner ads and an ad for the domain company userfriendly.com (apparently no relationship to the humorous userfriendly.org, according to the latter's FAQ). Many security sites and documents still point to ssleay.org, so apparently its loss was not announced and expected in the security community. I don't know who was in charge of it after the SSLeay creators went to RSA Australia. As any transition between providers would have been brief and the site content should have reappeared quickly, it seems someone unknown to the security community has grabbed that domain. It would be nice if someone in the community who knows who the SSLeay.org webmaster was could confirm if the new owner has any known security credentials. There are quite a few security web sites that need to find out if their links need updating. Anyone still pointing at SSLeay is 15 months behind the times. Cheers, Ben. -- http://www.apache-ssl.org/ben.html
Re: PRNG State [was: KeyTool internal state]
"Arnold G. Reinhold" wrote: I wonder if you are confusing the length in bits of a PKC key, e.g. a prime factor of an RSA public key, with the entropy of that private key. The prime factor may be 512 bits long, but it usually does not have anyway near 512 bits of randomness. Usually a secret prime is generated by adding a 128 or 160-bit random quantity to some non-secret base and then selecting the next prime number. In such a scheme a 20 bytes (160 bits) random pool is not unreasonable for generating one key or a small number of keys. In what sense is this "usual"? Who does it this way? On general principles I would prefer a larger pool of randomness, especially if it is available in the operating system, but if the 20 bytes are truly random, I don't think you can call the keytool scheme insecure. Certainly 160 bits of randomness would make it hard to crack! Cheers, Ben. -- http://www.apache-ssl.org/ben.html
Re: New York teen-ager win $100,000 with encryption research(3/14/2000)
"Arnold G. Reinhold" wrote:
At 7:39 PM -0800 3/14/2000, Eugene Leitl wrote:
Of course it ain't actual encryption, only (high-payload)
steganography at best. Now, if you sneak a message into a living
critter (a pet ("the message is the medium"), or creating the ultimate
self-propagating chainletter, a pathogen), that would be an
interesting twist.
Interesting is that you can tag the message with a longish
pseudorandom base sequence, which allows you to fish for the fragment
(from digests) via a complementary sequence. Anyone not in posession
of that sequence would have to do a total sequencing.
If you know the DNA sequences of alphabet letters, you can PCR probe
for common words or word fragments like "the" or "ing" and avoid
total sequencing.
This is the attack I suggested to the guys who published in Nature.
Their plan was to change the codons for each message, but I felt that
you could still probe for stretches of DNA containing codons of the
form, say, ABCABC and ABCDEF but not DEFDEF (i.e. ABC - 'e' and DEF -
'a'), and so forth.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER: http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe? http://ApacheCon.Com/
Re: Legal/patent analysis of Lucre?
"James A. Donald" wrote: -- At 10:23 AM 2/18/00 +, Ben Laurie wrote: A problem with continued development of Lucre is that various solutions to the coin marking problem have been proposed, and various opinions as to the likely patent-infringment-ness have been given, leaving me no clearer as to what the best way to proceed is. What is wrong with the original solution proposed in my original article, http://www.jim.com/jamesd/kong/anon_transfer.htm The client uses an existing used coin for blinding the newly created coin, preferably a coin that he got from someone else, not a coin issued to him by the issuer. If the coin issuer marks coins by using a different key for some coins and not others, the blinding will generate unrecognizable garbage and the system will fail. Guess that's another possibility to add to the list. Cheers, Ben. -- SECURE HOSTING AT THE BUNKER: http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html Coming to ApacheCon? http://ApacheCon.Com/
Re: Smartcard anonymity patents
lcs Mixmaster Remailer wrote: What are the prospects for smartcard based systems within the U.S.? Such cards are essentially nonexistent in commerce. Apparently in Europe and Asia they are widely used, though, instead of the credit cards preferred by Americans. I wouldn't go so far as that! I have a wide selection of traditional credit cards, and not very many smartcards. Almost all the smartcards I have are either in my phone or my TV. I do have a Mondex card, but I've yet to activate it, let alone use it. I have never used a smartcard for a financial transaction. I do use credit cards frequently, though. Cheers, Ben. -- SECURE HOSTING AT THE BUNKER: http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html Coming to ApacheCon? http://ApacheCon.Com/
Legal/patent analysis of Lucre?
A problem with continued development of Lucre is that various solutions to the coin marking problem have been proposed, and various opinions as to the likely patent-infringment-ness have been given, leaving me no clearer as to what the best way to proceed is. Is there anyone out there willing and qualified to evaluate the various approaches and decide which, if any, are viable? Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html Y19100 no-prize winner! http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: Coerced decryption?
Russell Nelson wrote: Caspar Bowden writes: And, as a result, the Bill proposes that the police or the security services should have the power to force someone to hand over decryption keys or the plain text of specified materials, such as e-mails, and jail those who refuse. Nobody's mentioned the possibility of an encryption system which always encrypts two documents simultaneously, with two different keys: one to retrieves the first (real) document, and the second one which retrieves to the second (innocuous) document. With such a system, it should be clear that coercing decryption has the same negative attributes as coercing self-incrimination. As an aside, why hasn't anybody mentioned this before? It seems obvious to me. Am I some sort of supergenius or something (more likely the latter, in my experience!)? Or is there an information source that I'm missing out on? Are people saying things about cryptography that don't make it to [EMAIL PROTECTED]? Julian Assange has long advocated (and implemented) such things, using an unknown number of keys, and a certain amount of excess entropy in the ciphertext, too. His intent, as is yours, is to provide a defence against coercion. Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html Y19100 no-prize winner! http://www.ntk.net/index.cgi?back=2000/now0121.txt
RSA flier?
Does anyone have a copy of the RSA flier going about with a picture of a car on the front, in which the scurrilous claim that free software is not supported or maintained is made? I had one, but its, err, in use by the ASA. :-) Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html Y19100 no-prize winner! http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: The problem with Steganography
Rick Smith wrote: It sounds like there are a number of interesting design questions. For example, the sender and recipient must obviously share a secret key. Why is that obvious? What's wrong with encoding with the recipient's public key? Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html Y19100 no-prize winner! http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: The problem with Steganography
Rick Smith wrote: Rick Smith wrote: It sounds like there are a number of interesting design questions. For example, the sender and recipient must obviously share a secret key. At 10:18 PM 01/26/2000 +, Ben Laurie wrote: Why is that obvious? What's wrong with encoding with the recipient's public key? It depends on what you're encoding. I expect we end up with a three step process: first, encrypt the data, second, stego it into the image or other file, and third, provide the recipient with information for recovering the hidden data. If we're talking about the first step, encryption of the raw data that's being stego'ed (is there a more legitimate verb for that?), then I'd prefer to use secret key encryption, since it introduces fewer uncertainties regarding the safety of the ciphertext. As to step 3, how this secret information is shared with potential recipients, public key techniques are fine. If we're talking about Russ Nelson's "forward stego" problem, then PK is overkill -- he just needs to publish the secret information and voila, the previously hidden information is uncovered. As to Russ' problem of how to keep the information "available," I suggest we look around our environments and take stock of what iconic images or files we all have and for some reason can't part with. Perhaps there's some really great crt wallpaper image that would do the job, or one could embed it in a Craig Shergold make-a-wish chain letter. Those things NEVER die. I can't quite see the point of forward stego. Why not publish something public key encrypted and publish the private key later? If you want a lot of people to see it, you can't keep it secret. If you can't keep it secret, you may as well just come out with it and publish the bits without stego. What did I miss? Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html Y19100 no-prize winner! http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: Response from Commerce Dept to Is this man a crypto-criminal?
Declan McCullagh wrote: Date: Tue, 18 Jan 2000 10:01:49 -0500 From: "JIM LEWIS" [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: "EUGENE COTTILLI" [EMAIL PROTECTED] Subject: Re: FC: Is this man a crypto-criminal? The Feds won't say... Declan: This point is worth clarifying. The new regs remove restrictions from the posting of publicly available encryption source code for downloading. The regs say: a) If you post encryption source code to a site on the net and anyone can access it, you do not need to have it reviewed by BXA or obtain a license. But isn't the whole point that he's posted binaries? Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: small authenticator
[EMAIL PROTECTED] wrote: I've got something with around 100 bytes of ram and an 8-bit multiply. Is there an authentication mechanism that can fit in this? HMAC? Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: BXA press release URL; and where to get the regs in HTML
Phil Karn wrote: What still confuses me are the circumstances that let you just send an email pointer to BXA, and which ones require a review of some sort before you can export. Well, the press release says: Global Exports of Unrestricted Encryption Source Code Encryption source code which is available to the public and which is not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed with the source code may be exported under a license exception without a technical review. The exporter must submit to the Bureau of Export Administration a copy of the source code, or a written notification of its Internet location, by the time of export. Foreign products made with the unrestricted source code do not require review and classification by the U.S. Government for reexport. This license exception should apply to exports of most "open source" software. Perhaps the easy answer is for someone to attempt such an export with email notification and see what BXA say about it! Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: starting up servers that need access to secrets
Rich Salz wrote: Another approach would be to double the number of systems that the adversary must compromise. HostA will run the service, but only when HostB sends it startup info. At boot A pings B. B "calls back" over over an SSL link and sends the passphrase using something like S/Key perhaps. Does that double the number of systems? Surely all the adversary has to do is substitute his own s/w for the thing that receives the passphrase and reboot A, not requiring a crack of B at all. Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Seven and a Half Nonrisks of PKI
I've been debating whether to ditch this or not, but I feel it needs to
be said. So, as the Duke of Wellington may, or may not, have said,
"publish, and be damned".
Cheers,
Ben.
.
Seven and a Half Non-risks of PKI: What You Shouldn't Be Told about
Public Key Infrastructure
By Ben Laurie.
Carl Ellison and Bruce Schneier wrote a critique of PKI, "Ten Risks of
PKI: What You're Not Being Told About Public Key Infrastructure",
which can be found here:
http://www.counterpane.com/pki-risks.html.
Whilst I agree with the conclusion ("Public-key infrastructure has
been oversold as the answer to many network security problems") I find
myself at odds with many of their arguments. So, I felt impelled to
write a response. And here it is.
It is also worth noting that, oversold or not, PKI is the only thing
we have right now that even remotely begins to solve some of the
problems we have.
Note that this will be almost meaningless unless read in conjunction
with the original article. "CEBS" are, of course, Carl Ellison and
Bruce Schneier, and are quoted from their article. "BL" is yours
truly.
CEBS: Before we start: "Do we even need a PKI for e-commerce?" Open any
article on PKI in the popular or technical press and you're likely to
find the statement that a PKI is desperately needed for e-commerce to
flourish. This statement is patently false. E-commerce is already
flourishing, and there is no such PKI. Web sites are happy to take
your order, whether or not you have a certificate.
BL: This is deliberately missing the point. Clients need no
certificate, but why would they? You don't need any kind of proof of
identity to buy things over the telephone or via mail order. However,
you'd be a fool to give money to someone you don't know in exchange
for a promise of goods. So, the shop is the one that needs (and,
indeed, has) a certificate. Proof that they are who they say they are.
CEBS: Risk #1: "Who do we trust, and for what?"
BL: Again, we seem to be talking about client certificates here, which
are not relevant. A server certificate, which is relevant, says just
one thing: that the holder of the certificate owns the corresponding
domain name (i.e. the domain name named in the certificate does indeed
belong to the purchaser of that certificate).
Now, it can be argued that CAs don't check this relationship as
thoroughly as they might, but I know of no instance where it has turned
out to be false, and they do make some effort to ensure it is true.
It can also be said that they don't stand behind this assertion with
any great conviction, and that would seem to be true - but whatever
their legal liability may be, a CA that was shown to be negligent in
these matters will be out of business, fast.
You might ask "what use is the certificate, in that case?"
The answer is simple: if you get burnt, it tells you who burnt
you. You can then seek compensation. This can be rather hard if you
simply buy from Joe Average on the Internet.
There's also a technical issue: the security used in SSL/TLS is
dependent on one end or the other having a certificate for its
integrity. So the certificate provides a value simply by linking the
public key to the server name - it secures your shopping session.
CEBS: Risk #2: "Who is using my key?"
BL: Client certificates again. They aren't the issue. Server
certificates _can_ be run in trusted environments, they _can_ have
good passwords. They _can_ be in tamperproof devices. And they often
are.
Of course, in every line of business, there will be those who don't
take the appropriate precautions. They will lose in the long run.
CEBS: Risk #3: "How secure is the verifying computer?"
BL: At last, a risk I can agree with! However, it should be noted that
the verifying computer in the interesting case is the client's
computer. Cracking it to accept a forged certificate is going to be a
lot of effort for rather small gain in most cases.
CEBS: Risk #4: "Which John Robinson is he?"
BL: When a certificate is used to verify a server DNS entry, there is
no possibility of confusion. Server names are globally unique, and
that's the end of it.
CEBS: Risk #5: "Is the CA an authority?"
BL: The logic in this argument is flawed. The fact that X is not "an
authority" on Y does not mean that X cannot make a correct, verifiable
statement about Y. We do not care whether the statements made by a
certificate are "authoritative", we care whether they are true.
And to answer the final rhetorical question: " What harm is done if an
uncertified server were allowed to use encryption?", the answer is
that it would be susceptible to a Man in the Middle attack.
CEBS: Risk #6: "Is the user part of the security design?"
BL: Once more, a point I have some sympathy with, but if you accept
that the
Re: Ten Risks of PKI
BPM Mixmaster Remailer wrote: By using this generic term "PKI" the authors leave a great deal of confusion about which systems they are criticizing. Some of their "risks", such as the one quoted above, would apply to all of these PKIs, including SPKI. Others are more specific to current X.509 based hierarchical certification systems. Some don't address the PKI at all, but worry about things like user interfaces, criticisms that can be directed at virtually any form of security software. Slightly tangentially, but worth observing, I think: current X.509 based PKI is only nominally hierarchical. That is, X.509 would _like_ the DN to be allocated hierarchically, but in practice this does not happen. Each CA has its own namespace, there is no-one above CAs in the hierarchy, and only one layer below (the entity for whom the CA provides a certificate). This is pretty flat for a "heirarchy" by anyone's reckoning. SPKI's main beefs with X.509 (AFAIK) are that: a) X.509 tends to want to be identity-based, which is a poorly defined concept at best (SPKI leans towards roles or capabilities) b) X.509 is based on a lot of difficult-to-get-right stuff that just gets in the way of the real meat: signing public keys and attaching some attributes to them. The fact that every X.509 package of any breadth is peppered with exceptions to cater for every other package's cockups is definitely evidence is SPKI's favour, IMO. The downside of SPKI, of course, is the usual one that seems to dog good ideas: no-one uses it. Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Debit card fraud in Canada
David Honig wrote: At 10:49 AM 12/13/99 -0500, Steven M. Bellovin wrote: true for credit cards? If so, a simple visual recorder -- already used by other thieves -- might suffice, and all the tamper-resistance in the world won't help. Crypto, in other words, doesn't protect you if the attack is on the crypto endpoint or on the cleartext. Wouldn't a thumbprint reader on the card (to authenticate the meat to the smartcard) be a tougher thing to shoulder surf? Does raise the cost over a PIN. Sure. But wouldn't you like to keep your thumbs? Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Thawte SuperCerts
Marcus Leech wrote: So: two questions (with a possible answer of "use the source, luke"): o What bits are set in a "super cert" to indicate that it's a SGC or step-up cert? Or is it simply that certs issued by a super-cert authority (as marked in the browser CA cert database) are always "step up" certs? The latter. o I'm thinking that there's a bit in the CA cert database that Netscape and IE maintain that says "OK to issue SGC certs". Anyone know where the bit is? Yes, it is known, at least for Netscape, but I'm afraid I've forgotten where it is documented. There's also a program to tweak Netscape's CA cert DB to mark a CA of your choice for SGC. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Export control of Java VM ??
Ron Rivest wrote: Here's a thought exercise: What happens if someone applies for an export license for a Java Virtual Machine, which he intends to use as an "encryption routine"? The idea (which is not new) is that a Java program (Java byte code) would be the "key" for the encryption. It specifies how to turn the input message into the output plaintext. Thus, the VM is doing the encryption work as specified by the byte-coded "key". Of course, you can make the same argument for, say, a Pentium. Also, anyone who has done their Turing machines 101 knows that any Turing machine can be rewritten as data (i.e. "a key") for the universal Turing machine... Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Universal Quantum Computers
People may be interested in last week's Nature article, D. Gottesman and I.L. Chuang, "Demonstrating the viability of universal quantum computation using teleportation and single-qubit operations", Nature 402, 390-392. One thing that should make software authors jump for joy is that the method involves quantum software that is hard to make yet is consumed during the computation. Enforcable software leasing, woo! [1] Whether it is of any significance that the authors work for Microsoft and IBM respectively I leave to the reader to decide. Cheers, Ben. [1] No, I don't think this is a good thing. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: a smartcard of a different color
Robert Hettinga wrote: --- begin forwarded text To: [EMAIL PROTECTED] Subject: a smartcard of a different color Date: Tue, 16 Nov 1999 22:15:07 -0500 From: Dan Geer [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Yesterday I saw a smartcard of a different color. In particular, it is the smartcard chip but in a key-ring thing that is more or less identical to the Mobil SpeedPass except that it has a USB connector on one end and a keyring hole on the other. Total length circa 1.25"; color purple; maker Rainbow Technologies. As my pal Peter Honeyman said in showing it to me, "There are already all the USB ports we'll ever need." I'd point out that without the 7816 requirement for flex a whole lot more memory is a trivial add-on and that USB is not a bandwidth bottleneck. I thought these were IDs and not dumbcards? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: size of linear function space
[EMAIL PROTECTED] wrote:
Consider functions of one variable whose domain and range are both
{0,1,2,...,n-1}. There are n^n possible functions.
n!, I'd say, since the range of any function that isn't one-to-one is
_not_ {0..n-1}. Did you mean that the range was a subset of {0..n-1}? Or
perhaps (equivalently) you meant to say "codomain" instead of "range"?
How many of these
are linear [i.e. F(a+b) = F(a) + F(b) + c, where c is the same for all
a,b (if it were different, that would be trivial)]? For any one
definition of +, there will be some number;
This strikes me as completely false. Can't be bothered to prove it,
though. Especially since the problem is currently not well-defined :-)
I'm interested in the sum
over all definitions of + that satisfy the usual requirements of
associativity, commutativity, additive identity, etc.
Hmm. This is horribly inexact. Do you mean the usual requirements for a
group? A field? What?
And like anonymous says, if you are going to ask these weird questions
(some of which are quite entertaining), you could at least say why.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Almost-Everywhere Superiority for Quantum Computing
Russell Nelson wrote:
Julian Assange writes:
Simon as extended by Brassard and H{\o}yer shows that there are
tasks on which quantum machines are exponentially faster than
each classical machine infinitely often. The present paper shows
that there are tasks on which quantum machines are exponentially
faster than each classical machine almost everywhere.
Okay, then can I ask a silly question (I prefer to contribute good
answers, but in this case hopefully the question is good enough)? If
quantum computers make brute-force cryptanalysis tasks easier, don't
they also make brute-force cryptographic tasks easier as well? Put
another way, is there something special about quantum computers that
is different from Intel's next process shrink? That is, apart from
the havoc it plays with key lifetime expectations?
Well, for example, if it makes public key cryptography no longer one
way, regardless of keysize, then we'd have to think of a new way to do
things. Which may be possible, of course. But PK was possible for a long
time before anyone thought of it.
If I understand the theory correctly, this is precisely what is going to
happen, too.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: unbreakable code? with cash prizes
John Gilmore wrote: [I'm just forwarding this with the expectation that someone might want to try for the prize. I don't know anything about the code. -gnu] No, no. You are forwarding it with the expectation that we'll all shout "snake oil" loud enough to deafen you. BTW, I offer $1,000 to anyone who can decrypt the hidden message in this message. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Ecash without a mint, or - making anonymous payments practical
[EMAIL PROTECTED] wrote: Anonymous says, (btw, I really wonder what's the point of having a technical discussion incognito... I hope this is not for a really good/bad reason such as you are living in some dark country), Frankly, I'm somewhat surprised. There are several really obvious reasons for having technical discussions anonymously: a) You don't have to live with any embarassing mistakes you may make b) If you are discouraged from having the discussion (e.g. by NDA, contract, disapproving boss), you still can c) You don't necessarily give away what your company is up to d) Men in black 'copters find it harder to know who to spirit away :-) But what most surprises me is that you think identity matters _at all_ in a technical discussion. Surely the discussion stands or falls on its merit, and nothing else? Now, if only I'd thought of a) before! Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: The well-travelled packet
Russell Nelson wrote: Forwarded with permission (the permission being the short quote below, the message being the long one). I don't have a copy of the traceroute, but it definitely showed packets going from Washington DC to NYC through Paris. This[1] is similar to the argument made to me by a UK FTP server operator (who shall remain nameless), when I was wondering about export controls on software from the UK - I said I was reluctant to export Apache-SSL, because I was not sure whether that was legal[2]. He said "put it on my server, then". I said, "but won't that get you into trouble if the export turns out to be illegal?". His response was that _he_ wasn't doing any exporting, nor was his machine. If anyone was, it would be the router on the border between the UK and wherever the downloader was (or the first international hop), which most certainly didn't belong to him or anyone he cared about. I'm still not convinced I believe this argument - though I should really seek legal advice before seriously doubting it. For example: if I send munitions in the post to parts exotic, can I really claim that it was the Post Office that did the export? I think not. But I suspect there are special rules for the Post Office that ISPs do not enjoy the benefit of. Cheers, Ben. [1] The idea that packets routed from US-somewhere-US may violate export regs. [2] I'm now pretty damn sure it is. But I still don't. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: RSA Security, Inc.
Vin McLellan wrote: Why did Baltimore Tech's founder flip out and denounce RSA's PKC as a secret stolen from the British GCHQ... shortly after RSA-Australia began shipping Eric Young's new SSL implementation code under the RSA brand name in the international market? (Young's BSAFE SSL-C was the first challenge from RSADSI to Baltimore and other non-American vendors which have sold full-strength RSA PKC for years.) Errr. New? Slight terminological inexactitude there. Try "old". And since we are in the questioning mood, why is it that far more people use OpenSSL than BSAFE SSL-C? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Why did White House change its mind on crypto?
Declan McCullagh wrote: Another answer might lie in a little-noticed section of the legislation the White House has sent to Congress. It says that during civil cases or criminal prosecutions, the Feds can use decrypted evidence in court without revealing how they descrambled it. If you can not reveal how you descramble it, doesn't that mean you can't be asked to show that it actually corresponds to the ciphertext? Scary! Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: IP: Admin Plans to Loosen Encryption Restrictions
Bill Frantz wrote: At 9:56 AM -0700 9/14/99, Robert Hettinga forwarded: Source: New York Times http://www.nytimes.com/library/tech/99/09/cyber/capital/14capital.html September 14, 1999 By JERI CLAUSING Administration Plans to Loosen Encryption Restrictions In June, the President's Export Council Subcommittee on Encryption sent the White House a report recommending the Administration loosen its restrictions on encryption technology to allow for the export of consumer products based on a 128-bit key. That is significantly stronger than the current limit on encryption products exempt from control. My reading said that while you could export 128 bit encryption, you were still limited to 512 bit discrete log/RSA for key agreement. With that restriction, only spies, drug dealers, and others who can exchange keys via physical means can have strong encryption. Don't the current rules allow 1024 bits? (Which makes me think the NSA know something about factoring that we don't). Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: And now, a java encoder ring!
Andreas Bogk wrote: Udhay Shankar N [EMAIL PROTECTED] writes: For me, the highlight of the JavaOne Developer Conference in San Francisco last March was Dallas Semiconductor's iButton with Java -- aka the Java Ring, a wearable computer that ran Java. It allegedly had a high-performance encryption engine, an exciting prospect indeed, until I discovered that the encryption unit wasn't accessible on the ring. Funny. I'm holding in my hands a version of the Java ring that _does_ RSA (I've checked, up to 1024 bit key length). Funny because I'm in Germany and Dallas legally exported one to me. I'm wondering what _that_ means. Can you say backdoor? I checked this recently. Dallas have a licence to export them. This is no surprise, because 1024 bit RSA is now exportable. The thing that has surprised people is that Dallas until recently did not give access to the crypto engine from Java. This has recently changed. I think they forgot to announce it, which is weird, but there you are. Now, all I need is a ring and some time to get iBLab talking to it ... or is someone going to volunteer for that? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Apache-SSL 1.3.6+1.36 released, with Keynote support!
Changes with Apache-SSL 1.3.6/1.36 *) Add experimental Keynote (http://www.cis.upenn.edu/~keynote) support. Not only does this provide a very cool way to do stuff based on certificate attributes (and more), but it also demonstrates that it is possible to write independent add-on modules for Apache-SSL. [Ben Laurie] *) Remove spurious printf. [Stefano Ravaioli [EMAIL PROTECTED]] *) Add note about environment variables to 1.35 changes. [Ben Laurie] *) Add SSLDenySSL directive. [Bruce Tenison [EMAIL PROTECTED], revised by Ben Laurie] Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: If only you knew what we knew
"James A. Donald" wrote: -- From time to time the spooks have a talk with various people about the restrictions on cryptography, and those people stop opposing the restrictions, and tell us "if only you knew what we knew" i.e. how much dirt the spooks have on them :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: depleting the random number generator
David Honig wrote: Ben suggests using "hashcash" to prevent malicious depletion of the entropy pool, where the "hashcash" (hashes that are expensive to compute but cheap to verify) becomes the limiting resource instead of the server's MIPS. This prevents DoS attacks but doesn't solve the problem of a VPN server running out of cryto-quality randomness, which it could easily do under normal usage. I think we all agree that you can't fool mother nature (ie, entropy is conserved) and if your legitimate users are consuming too much randomness, you need a higher bandwidth source. That's true, of course, but the question was how to prevent the DoS. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: depleting the random number generator
bram wrote: On Mon, 19 Jul 1999, Enzo Michelangeli wrote: Sorry folks, but I can't understand where the problem is supposed to be. The entropy of a pool is a measure of the information about its internal state that we don't know: which is why in thermodynamics the same name is given to the logarithm of the number of (invisible) microstates corresponding to an (observed) macrostate. Now: if we extract bits from the generator, we cannot gain insight over the internal state and its evolution, because on the path of a well-designed RNG there is a one-way function whose inversion is not computationally feasible. That's true, but not horribly obvious to most people, and the design of the random number gizmo isn't all that trivial. The brief summary of the above is that it's possible to simply replace /dev/random with something which doesn't deplete entropy and the problem will go away. And yes, it is possible to do that in a secure manner. So what you are saying is that you'd be happy to run your server forever on an inital charge of 128 bits of entropy and no more randomness ever? Really? This model should work for all the servers in the world, of course (operating from a single initial charge of 128 bits shared between them). Are we all happy? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: depleting the random number generator
David Honig wrote: At 04:45 PM 7/17/99 -0400, John Denker wrote: Hi Folks -- I have a question about various scenarios for an attack against IPsec by way of the random number generator. The people on the linux-ipsec mailing list suggested I bring it up here. ..worries that /dev/random exhaustion - DoS, and /dev/urandom - PRNG after exhaustion.. You are correct. There is no way around this, except to add a true RNG to your server. With an open source OS, you can add this to the existing /dev/[u]random code That isn't a way around it, that just gives you higher speed randomness. The obvious way to solve the underlying problem, as I've already said, is to use hashcash. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Lucre documentation
For those who care, I've added a little docco to Lucre. Here's the explanation of the executable demos. Also available is the theory, such as it is (check out the CVS for that, or shout at me). bank-new key length bank private file bank public file Create a bank. The stuff you should guard with your life is added to bank private file and the stuff you can give to Joe Public ends up in bank public file. coin-request bank public file coin private file coin request Create a coin (or at least, a request for one. What is sometimes known as a protocoin). The bank public file is the bank info generated by bank-new. The coin private file is the bit that will be worth money once the bank has signed stuff. The coin request is what the bank will sign. bank-sign bank private file coin request coin signature Having received a coin request, the bank signs it (after due deliberation, of course). Here's how it does it. coin signature is what you send back to the victim, err, customer. coin-unblind bank public file coin private file coin signature coin Now that the bank believes we are worth something, we've got a coin signature back from it. Here's how we convert that, plus other bits, to an actual blinded coin. bank-verify bank private file coin Naturally, a coin is worth nothing unless the bank will stand behind it. This is how you check the coin isn't crap. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Clear Session ID in SSLV3
"Marcus J. Ranum" wrote: Does anyone have a pointer to why the session ID in SSLV3 is in the clear, rather than encrypted? I'm sure there's a good reason for it (audit? logging? other...?) but I'm trying to pin down exactly why it was done that way. Can anyone point me in the right direction? Because the session ID is used to restore the shared cryptographic environment, for performance reasons. Hence it has to be in the clear. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Word needed for Entropy
Carl Ellison wrote: I've been guilty of sloppy use of English, occasionally, and one such sloppiness that I run into occasionally is with the word "entropy" for cryptographic purposes. What we need is a word or very short phrase to capture the full phrase: "the conditional entropy of a measurement given all the information about the measurement that an attacker is expected to acquire, under the threat model for which the present use is being designed." In casual language, I might call this "undiscoverability", but it's far too large a word. "effective randomness"? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Lucky Green wrote: OpenSSL is a library. It should support whatever the standard supports and whatever users and/or authors of the lib desire to be in the lib. That may include broken or null-ciphers. But the user should have to take positive action to get at the broken ciphers. I believe by default, OpenSSL should ship with the weak ciphers disabled. And there should be a clear warning: "Not secure, don't fool yourself, do not use, etc]". Its funny you should say that, because I was just working around to the same conclusion myself. I anticipate resistance from both users and some of the other developers, because it will break almost every out-of-the-box installation, and it will be argued that the "user experience" is far more important that this piffling security stuff. Sigh. Ah well, here goes. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Adam Back wrote: My arguments that adding broken ciphersuites to an IETF standard was in direct and obvious violation of RFC 1984 fell on deaf ears, as Netscape, microsoft and even openSSL (in the form of Ben Laurie) busily rushed and implemented the proposed broken ciphersuites. OpenSSL has them disabled by default. But I am torn on this question: these new ciphersuites give greater strength than existing ones when interopping with export stuff. Is it sensible to refuse to add stronger ciphersuites? If it isn't, because they are crap, should we (the OpenSSL team) disable _all_ export ciphersuites? I mainly implemented them because they required extensions to the ephemeral RSA key generation (to specify the number of bits), and I wanted to add that long before it was actually needed. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Adam Back wrote: I presume that the TLS WG is planning to use DES to replace the RC4 40 bit cipher that was used for export compliance. I saw no indication that this was the case, though this sounds better than just adding DES and leaving all the 40 bit ciphersuites intact which looks like what the current plan is by my reading. There's no indication either way, since the new ciphersuites are a standalone I-D, not a modification to TLS. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: MPI Modular Arithmetic
Terence Kelly wrote: A friend of mine reported that when he ran a battery of straightforward random tests on the GNU package, it failed on simple inputs (things like "4 + 4"). It takes very little effort to set up random tests and run them, and this kind of testing reveals bugs in several multi-precision arithmetic packages. You might check out the very well-documented arithmetic packages in Dave Hanson's book _C Interfaces and Implementations_. Source code is available at http://www.cs.princeton.edu/software/cii/ If tests (random or otherwise) convince you that none of the packages available in source form are correct, Knuth Vol. 3 contains a reasonable discussion of multiple-precision arithmetic, as do the _Numerical Recipes_ books. OpenSSL's tests include random tests, which are verified both internally (by doing the same sum a different way, or otherwise checking the answer) and externally (by checking them with bc). They do occasionally reveal weird compiler bugs. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Public-Key algorithm
Hans Viens wrote: Anyone know where a could get a public/private key generator (just like PGP) but not RSA... DH ??? Well, an algorithm that works with a test main and free... OpenSSL? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: How to donate a clue to a lawyer?
EKR wrote: If your purpose in using code is to communicate with other humans, what you want to communicate is intention with only the barest amount of procedure. However, in reality programs are almost all procedure with the barest amount of structure to attempt to communicate intention to humans who need to work on it. Don't get it. In a programming context, what is the difference between intention and procedure? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: FW: FW: Bernstein Opinion Up
Elyn Wollensky wrote: -Original Message- From: Lance Rose [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Friday, May 07, 1999 8:58 AM To: Elyn Wollensky Cc: [EMAIL PROTECTED] Subject: Re: FW: Bernstein Opinion Up [snip] - the fact that we reach for the easiest, broad purpose reference system that works, originally derived from human language, does not turn our use of this tool in computer programming into human-to-human speech This misses the point, totally. If someone wants me to explain how an algorithm works, or how to best set up a data structure, or how to write a program, I write code. Real code. In C++, usually. I may be weird, but I'm definitely human and not a computer, and so are the people I write the code for. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: New Intel Celeron chip set has random number generator
John Gilmore wrote: There have been mumbles about a random number generator in Intel executives' statements, but no solid information (e.g. where in the product line is this coming out?) until today. I noticed it at RSA's web site, but there's very sketchy info at the Intel site also. No technical details or programming information are yet available. Aha! Perhaps this explains why I got a distinctly luke-warm reception from Intel when I asked how I could go about using the randomness in OpenSSL. Wouldn't do to go around upsetting monopolistic friends, would it? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Rainbow technologies to use P3 serial number.
Austin Hill wrote: So if I want to visit e-commerce sites from one of my 6 machines (Which include a Macintosh, Sun and 4 Pentium's/Pentium Pro's) after having visited with my new P3 I'll not be able to get access?Chat rooms, corporate extranets and ecommerce sites such as Amazon are now going to turn away customers who aren't using the same PC all the time? This is a stupid way to build authentication. Lugging around my desktop PC to authenticate myself is not intelligent.You would think Rainbow, Intel and others would stop throwing around the bogus claims that this is good for theft prevention and authentication.The only real practical use is for corporate IS managers to manage inventory (Which can be done otherways) and reduce cost of ownership, and also to enforce per processor software lisensing.All this talk about ecommerce and theft prevention is bogus. You forgot the other side of the coin: i.e. padlocking my processor to prevent my colleagues/wife/children/cleaner from spending all my money is also a nonstarter. Especially since it seems I can't... Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Network Week demonstrate complete lack of clue
In an article entitled "56-bit cipher defeated in just 22 hours", Network Week (3 Feb 1999) say "Eric Young and Tim Hudson used 'brute force' - trying every possible combination - on a $250,000 custom-built super PC". Yeah, right! Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Intel announcements at RSA '99
Steve Bellovin wrote: Intel has announced a number of interesting things at the RSA conference. The most important, to me, is the inclusion of a hardware random number generator (based on thermal noise) in the Pentium III instruction set. They also announced hardware support for IPSEC. An interesting question (for me, at least) is: how will I know that the hardware RNG is really producing stuff based on thermal noise, and not, say, on the serial number, some secret known to Intel, and a PRNG? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: RSA's Australian deal
Steve Bellovin wrote: "The key to that is neither U.S. technology or U.S. personnel could be involved in making the product", according to DoC. Hmmm ... so SSL, RC4, DH etc., etc. are not U.S. technology, eh? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: DCSB: Risk Management is Where the Money Is; Trust in Digital Comm
Enzo Michelangeli wrote: -Original Message- From: Anonymous [EMAIL PROTECTED] Date: Thursday, November 12, 1998 4:42 AM [...] There is one potential fly in this ointment, and I do not intend to dwell on it, but I cannot get this far and not mention the threat to strong security apparati of having them undermined by key escrow. This is a red herring. The main issues in electronic commerce are authentication and authorization, not secrecy and encryption. The latter points can be important, but they are not crucial for commerce to proceed in the way that binding contractual commitments are. Key escrow does not apply to signature keys. No proposal for key escrow asks for signature keys to be escrowed. Only encryption keys are escrowed. Alas, the latest proposals by the Department of Trade and Industry in UK are to extend legal protection only to digital signatures whose keys are escrowed with OFTEL (the UK Govt. telecom regulator). See: http://omnisite.liberty.org.uk/cacib/artview.php3?currentgroup=3pid=12type =resources Actually, not. Even the DTI aren't quite that mad. If you want to be a licenced CA you have to escrow any encryption keys you get your hands on, not signing keys. Legal protection will be given only to signatures made with keys lodged with licenced CAs. Note: OFTEL is a branch of the executive, NOT of the judiciary... To make it worse, the keys can be obtained by a "senior police officer" (whatever that may mean), and tipping off someone that his/her key has been obtained by the police will constitute criminal offense. Be ready to pay for purchases made by some crooked cop... Note that none of this has actually happened yet. Also OFTEL is being touted as the issuer of licenses, not the escrower of keys. I wonder if they have read Rivest's paper on chaffing and winnowing, and concluded that after all also digital signatures are highly subversive... Close, but no cigar. Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
