Re: [Cryptography] PGP Key Signing parties
On Oct 10, 2013, at 2:31 PM, John Gilmore wrote: >> Does PGP have any particular support for key signing parties built in or is >> this just something that has grown up as a practice of use? > > It's just a practice. I agree that building a small amount of automation > for key signing parties would improve the web of trust. > > I have started on a prototype that would automate small key signing > parties (as small as 2 people, as large as a few dozen) where everyone > present has a computer or phone that is on the same wired or wireless > LAN. Phil Zimmerman and Jon Callas had started to work on that around 1998, they might still have some of that design around. --Paul Hoffman ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
Also see RFC 3766 from almost a decade ago; it has stood up fairly well. --Paul Hoffman ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Google's Public Key Size (was Re: NSA and cryptanalysis)
On Sep 4, 2013, at 2:15 PM, Andy Steingruebl wrote: > As of Jan-2014 CAs are forbidden from issuing/signing anything less than 2048 > certs. For some value of "forbidden". :-) --Paul Hoffman ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Folly of looking at CA cert lifetimes
At 5:33 PM -0400 9/14/10, Thor Lancelot Simon wrote: >On Tue, Sep 14, 2010 at 08:14:59AM -0700, Paul Hoffman wrote: >> At 10:57 AM -0400 9/14/10, Perry E. Metzger did not write, but passed on for >> someone else: >> >This suggests to me that even if NIST is correct that 2048 bit RSA >> >keys are the reasonable the minimum for new deployments after 2010, >> >much shorter keys are appropriate for most server certificates that >> >these CAs will sign. The CA keys have lifetimes of 10 years or more; >> >the server keys a a quarter to a fifth of that. >> >> No, no, a hundred times no. (Well, about 250 times, or however many >> CAs are in the current OS trust anchor piles.) The "lifetime" of a "CA >> key" is exactly as long as the OS or browser vendor keeps that key, >> usually in cert form, in its trust anchor pile. You should not >> extrapolate *anything* from the contents of the CA cert except the key >> itself and the proclaimed name associated with it. > >I don't understand. The original text seems to be talking about *server* >certificate lifetimes, and how much shorter they are than CA cert >lifetimes. What does that have to do with "a thousand times no" about >some proposition to do with CA cert lifetimes? > >In other words, if CA key lifetimes are longer than indicated by their >X.509 properties, it seems to me that just makes the quoted text about >the relationship between server and CA key lifetimes even more true. Ah, I see what you are saying, and what Perry's anonymous forwarder meant. That is, if the "CA keys have lifetimes of 10 years or more" means "because that's how long OSs and browsers leave them in the trust anchor pile", then it has nothing to do with the built-in notAfter dates in the server certificates. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Folly of looking at CA cert lifetimes
At 10:57 AM -0400 9/14/10, Perry E. Metzger did not write, but passed on for someone else: >This suggests to me that even if NIST is correct that 2048 bit RSA >keys are the reasonable the minimum for new deployments after 2010, >much shorter keys are appropriate for most server certificates that >these CAs will sign. The CA keys have lifetimes of 10 years or more; >the server keys a a quarter to a fifth of that. No, no, a hundred times no. (Well, about 250 times, or however many CAs are in the current OS trust anchor piles.) The "lifetime" of a "CA key" is exactly as long as the OS or browser vendor keeps that key, usually in cert form, in its trust anchor pile. You should not extrapolate *anything* from the contents of the CA cert except the key itself and the proclaimed name associated with it. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: 2048-bit RSA keys
At 11:35 AM +1000 8/16/10, Arash Partow wrote: >Paul Hoffman wrote: >>You are under the wrong impression, unless you are reading vastly different >>crypto literature than the rest of us are. RSA-1024 *might* be possible to >>break in public at some point in the next decade, and RSA-2048 is a few >>orders of magnitude harder than that. >> > >Just out of curiosity, assuming the optimal use of today's best of breed >factoring algorithms - will there be enough energy in our solar system to >factorize a 2048-bit RSA integer? We have no idea. The methods used to factor number continue to slowly get better, and it has been quite a while since there was a single large improvement. That could mean that there are no more improvements to be made, or that some smart cryptographer who isn't focused on the SHA-3 competition is about to make another big improvement, or something in between. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
2048-bit RSA keys
At 9:34 AM -0700 8/15/10, Ray Dillinger wrote: >I'm under the impression that <2048 keys are now insecure mostly due >to advances in factoring algorithms that make the attack and the >encryption effort closer to, but by no means identical to, scaling >with the same function of key length. You are under the wrong impression, unless you are reading vastly different crypto literature than the rest of us are. RSA-1024 *might* be possible to break in public at some point in the next decade, and RSA-2048 is a few orders of magnitude harder than that. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: /dev/random and virtual systems
At 10:38 PM +0300 8/2/10, Yaron Sheffer wrote: >the interesting thread on seeding and reseeding /dev/random did not mention >that many of the most problematic systems in this respect are virtual >machines. Such machines (when used for "cloud computing") are not only >servers, so have few sources of true and hard-to-observe entropy. Often the >are cloned from snapshots of a single virtual machine, i.e. many VMs start >life with one common RNG state, that doesn't even know that it's a clone. > >In addition to the mitigations that were discussed on the list, such machines >could benefit from seeding /dev/random (or periodically reseeding it) from the >*host machine's* RNG. This is one thing that's guaranteed to be different >between VM instances. So my question to the list: is this useful? Is this >doable with popular systems (e.g. Linux running on VMWare or VirtualBox)? Is >this actually being done? It is certainly doable: put a "file" on the host whose contents are random and change every second. On the VM, read that file on wakeup or boot and mix it into /dev/random. This guarantees a different value for each wakeup/boot, but not that every cloned machine that starts will have a unique state (because they might start within the same refresh. If you need that, you probably want to automatically mix a microsecond-accurate time at the same time. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Root Zone DNSSEC Deployment Technical Status Update
At 9:52 AM -0400 7/17/10, Thierry Moreau wrote: >Incidentally, you say you [the design team] had good *documented* reasons for >implementing DURZ *as*you*did*. Did you document why any of >unknown/proprietary/foreign signature algorithm code(s) were not possible >(this was an alternative)? This was my outstanding question. Thierry, can you say how using one of those alternatives would look different than the DURZ that they used? Should they all be marked as "unverfied" in a compliant DNSSEC resolver? If not, I am interested in how you think the differences would have manifest in the real world. >>Yes, they are - see http://data.iana.org/ksk-ceremony/. If there is anything >>missing, please let me know. >> > >Thanks, great. The two key ceremony scripts are what I wanted to look at. FWIW, this was *widely* publicized, particularly on mailing lists that Thierry is on. It even made the IT trade press. As a side note, I find the IT press part disturbing, given that the key signing ceremonies were just as much security theater as many of the things we like to chide on this list. >I don't have a question. I will trust the DNSSEC root signatures. However, it >seems obvious that formal dual-control rules should have been designed, e.g. a >"Trusted Courier Officer" role with a 3 out of 4 (or 5) separation of duty. >Without this, the key material has been protected only by the tamper-evident >protection in transit from the ECF to the WCF. This role would have been >limited in time. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
The EC patent issues discussion
At 9:40 PM -0400 4/20/10, Victor Duchovni wrote: >EC definitely has practical merit. Unfortunately the patent issues around >protocols using EC public keys are murky. This is starting to turn around. More vendors are questioning the murk. Please see <http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc>. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Quantum Key Distribution: the bad idea that won't die...
At 11:31 AM -0400 4/20/10, Perry E. Metzger wrote: >I wonder why it is that, in spite of almost universal disinterest in the >security community, quantum key distribution continues to be a subject >of active technological development. You hit it: "almost". As long as a few researchers are interested, and there is money to be thrown down the drain^w^w^wat them, there will be active development. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: AES-CBC + Elephant diffuser
At 2:24 PM +0100 10/29/09, Eugen Leitl wrote: >"We discuss why no existing cipher satisfies the requirements of this >application". Uh-oh. Yeah, we all know what a light-weight and careless person Neils Ferguson is. Who would listen to him? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
At 7:54 PM -0400 10/14/09, Perry E. Metzger wrote: >There are enough people here with the right expertise. I'd be interested >in hearing what people think could be done with a fully custom hardware >design and a budget in the hundreds of millions of dollars or more. What part of owning a temporary private key for the root zone would be worth even 10% of that much? There are attacks, and there are motivations. Until we know the latter, we cannot put a price on the former. Related question: if all the root keys were 2048 bits, who do you think would change the way they rely on DNSSEC? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: SHA-1 and Git
At 9:39 AM -0400 8/25/09, Perry E. Metzger wrote: >Ben Laurie writes: > > Perry E. Metzger wrote: >>> Yet another reason why you always should make the crypto algorithms you >>> use pluggable in any system -- you *will* have to replace them some day. >> >> In order to roll out a new crypto algorithm, you have to roll out new >> software. So, why is anything needed for "pluggability" beyond versioning? > >For one example, it is not theoretical that some people will often want >to use different algorithms than others and will need negotiation. Some >things like SSH have approximately done this right. Others have done >this quite wrong. > >When we were planning out IPSec, a key management protocol, SKIP, was >proposed that had no opportunity for negotiating algorithms at all -- >they were burned into the metal. As it happens, by now we would have had >to completely scrap it. > >Of course you can go too far in the other direction. IPSec is a total >mess because there are far too many choices -- the standard key >management protocols are so jelly-like as to be incomprehensible and >unconfigurable. Perry is completely correct on the two previous paragraphs. Hard-coded algorithms, particularly asymmetric encryption/signing and hash algorithms, will lead to later scrapping and a transition for the entire protocol. But it is quite easy to build a protocol with too many knobs, and IPsec is living proof of that. TLS's fixed, registered ciphersuites are far from perfect, but in retropsect, they seem a lot better from an operations / deployment standpoint than IPsec. > > It seems to me protocol designers get all excited about this because > > they want to design the protocol once and be done with it. But software > > authors are generally content to worry about the new algorithm when they > > need to switch to it - and since they're going to have to update their > > software anyway and get everyone to install the new version, why should > > they worry any sooner? > >You speak of "beyond versioning" as though introducing versioning or >algorithm negotiation were a trivial thing, but I don't think you can >generally tack such things on after the fact. You have to think about >them carefully from the start. A different answer to Ben would be "because not planning sooner causes your software users more grief". If you build in both algorithm agility and a few probably-good algorithms, the operational changes needed when one algorithm fails is low. Later software updates that contain other changes can also include new algorithms that are suspected to be good even if all of the original ones fail. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Certainty
At 7:10 PM -0700 8/19/09, james hughes wrote: >On Aug 19, 2009, at 3:28 PM, Paul Hoffman wrote: >>I understand that "creaking" is not a technical cryptography term, but >>"certainly" is. When do we become "certain" that devastating attacks on one >>feature of hash functions (collision resistance) have any effect at all on >>even weak attacks on a different feature (either first or second preimages)? >> >>This is a serious question. Has anyone seen any research that took some of >>the excellent research on collision resistance and used it directly for >>preimage attacks, even with greatly reduced rounds? > >This is being done. What Perry said. At 9:02 PM -0700 8/19/09, Greg Rose wrote: >Not directly, as far as I know. But some research and success on preimages, >yes. Getting a straight answer on whether or not the recent preimage work is actually related to the earlier collision work would be useful. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Crypto '09 rump session summary?
At 2:46 PM -0700 8/19/09, Greg Rose wrote: ...some summaries of some of the presentations... More like this, please! The rump sessions have a lot of value (beyond the often-strained attempts at humor). --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Certainty
At 5:28 PM -0400 8/19/09, Perry E. Metzger wrote: >I believe attacks on Git's use of SHA-1 would require second pre-image >attacks, and I don't think anyone has demonstrated such a thing for >SHA-1 at this point. None the less, I agree that it would be better if >Git eventually used better hash functions. Attacks only get better with >time, and SHA-1 is certainly creaking. I understand that "creaking" is not a technical cryptography term, but "certainly" is. When do we become "certain" that devastating attacks on one feature of hash functions (collision resistance) have any effect at all on even weak attacks on a different feature (either first or second preimages)? This is a serious question. Has anyone seen any research that took some of the excellent research on collision resistance and used it directly for preimage attacks, even with greatly reduced rounds? The longer that MD5 goes without any hint of preimage attacks, the less "certain" I am that collision attacks are even related to preimage attacks. Of course, I still believe in hash algorithm agility: regardless of how preimage attacks will be found, we need to be able to deal with them immediately. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: 112-bit prime ECDLP solved
At 7:54 AM -0600 7/18/09, Zooko Wilcox-O'Hearn wrote: >This involves deciding whether a 192-bit elliptic curve public key is strong >enough... Why not just go with 256-bit EC (128-bit symmetric strength)? Is the 8 bytes per signature the issue, or the extra compute time? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RE: HSM outage causes root CA key loss
At 11:09 PM +0200 7/14/09, Weger, B.M.M. de wrote: >Any other problems? Maybe something with key rollover or >interoperability? Bingo. Key rollover has been thinly tested in relying parties. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MD6 withdrawn from SHA-3 competition
At 10:39 AM -0700 7/4/09, Hal Finney wrote: >But how many other hash function candidates would also be excluded if >such a stringent criterion were applied? Or turning it around, if NIST >demanded a proof of immunity to differential attacks as Rivest proposed, >how many candidates have offered such a proof, in variants fast enough >to beat SHA-2? The more important question, and one that I hope gets dealt with, is what is a sufficient proof. We know what proofs are, but we don't have a precise definition. We know what a proof should look like, sort of. Ron and his crew have their own definition, and they can't make MD6 work within that definition. But that doesn't mean that NIST wouldn't have accepted the fast-enough MD6 with a proof from someone else. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MD6 withdrawn from SHA-3 competition
At 11:49 PM -0400 7/3/09, Steven M. Bellovin wrote: >Here's the essential paragraph: > > Thus, while MD6 appears to be a robust and secure cryptographic > hash algorithm, and has much merit for multi-core processors, > our inability to provide a proof of security for a > reduced-round (and possibly tweaked) version of MD6 against > differential attacks suggests that MD6 is not ready for > consideration for the next SHA-3 round. At 10:12 AM + 7/4/09, Brandon Enright wrote: >It wasn't entirely clear to me if it really was withdrawn. Ron Rivest >posted on behalf of the MD6 team some thoughts on MD6 performance and >specifically suggested/requested that NIST ask for submitted algorithms >to be "provably resistant to differential attacks". I agree more with Brandon than with Steve, but who knows. I read Ron's message as a challenge to NIST about whether or not NIST would really rely on the proofs. It was clear they didn't want to withdraw MD6, but that they felt like they had to because of the speed requirement. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Factoring attack against RSA based on Pollard's Rho
At 8:07 PM -0700 6/5/09, Greg Perry wrote: >Greetings list members, > >I have published a unique factoring method related to Pollard's Rho that >is published here: > >http://blog.liveammo.com/2009/06/factoring-fun/ > >Any feedback would be appreciated. Is there any practical value to this work? That's a serious question. The main statement about the value is "This is a factoring attack against RSA with an up to 80% reduction in the search candidates required for a conventional brute force key attack." Does that mean that it reduces the search space for a 1024-bit RSA key to, at best 205 bits (0.2 * 1024) of brute force? That is a silly reduction; reducing it to anything less than the estimate for NFS (about 80 bits) is not useful. Or, can this attack be combined with NFS? Or...? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
End-of-chapter questions for "Practical Cryptography"?
Greetings again. I'm helping someone new to the field learn cryptography. He's a book-learner, and is starting with Ferguson & Schneier "Practical Cryptography". I would love to give him some things to think about after each chapter to make sure he's thinking about the big picture. Has anyone on this list used the book to teach a class? If so, did you create a list of discussion questions? Or, do people know profs who have used the book to teach? Any pointers are appreciated. --Paul Hoffman - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Has any public CA ever had their certificate revoked?
At 6:02 PM +0200 5/8/09, R. Hirschfeld wrote: > > Date: Tue, 5 May 2009 10:17:00 -0700 >> From: Paul Hoffman > > > the CA fixed the problem and researched all related problems that it >> could find. > >>From what I've read of the incident (I think it's the one referred >to), Comodo revoked the bogus mozilla.com cert and got their reseller >Certstar (who issued it) to start performing validation. Correct. >Security >common sense might suggest that they validate all certs previously >issued by Certstar and check the validation procedures of their other >resellers. Do you know whether they did so? Comodo publicly said they did. That's why I said "researched all related problems that it could find". >The former seems a major >undertaking and commercially delicate. And yet they appear to have done it. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: 80-bit security? (Was: Re: SHA-1 collisions now at 2^{52}?)
At 8:54 PM -0400 5/6/09, Steven M. Bellovin wrote: >On Thu, 30 Apr 2009 17:44:53 -0700 >Jon Callas wrote: > >> The accepted wisdom >> on 80-bit security (which includes SHA-1, 1024-bit RSA and DSA keys, >> and other things) is that it is to be retired by the end of 2010. > >That's an interesting statement from a historical perspective -- is it >true? That's an oddly-worded question. It is true that NIST has specified that algorithms with 80 bits of effective strength should stop being used in US government systems after the end of 2010. It is not true that the accepted wisdom is 80-bit crypto "is to be retired" by the end of 2010. It is true that some uses of SHA-1 have 80 (now many fewer) bits of effective strength. It is not true that SHA-1 gives 80-bit security; many uses of a hash rely on the preimage resistance, not the collision resistance. It may be true that 1024-bit RSA and DSA gives 80 bits of effective strength, and it is true that this is the accepted wisdom. This is based on some wild hand-waving and scaling assumptions with very few data points, and particularly few in the past five years since that number became oft-repeated accepted wisdom. >And what does that say about our ability to predict the future, >and hence to make reasonable decisions on key length? Bupkis. The best asymmetric attack published so far is about 700 bits. No one has produced a SHA-1 collision at 62 bits of effort (the previous estimated work). Our ability to extrapolate work effort to 80 bits is questionable indeed. >See, for example, the 1996 report on key lengths, by Blaze, Diffie, >Rivest, Schneier, Shimomura, Thompson, and Wiener, available at >http://www.schneier.com/paper-keylength.html -- was it right? How could we tell? The whole point of the paper was estimating the strength needed to keep a secret *for a long time*. We are only 13 years into the 20 years that they used as a basis for the estimate of 90 bits. >In 1993, Brickell, Denning, Kent, Maher, and Tuchman's interim report >on Skipjack (I don't believe there was ever a final report) stated that >Skipjack (an 80-bit cipher) was likely to be secure for 30-40 years. >Was it right? Asking that question six years into the 30 years (if those were the numbers they used) is begging to make approximations on insufficient data. >The problem with SHA-1 is not its 80-bit security, but rather that it's >not that strong. That's one problem. Another is that because it can also be used in environments where 160ish bits of security are needed and it's still believed to be fine there, people on this list and in the press are sloppy when they speak about its use. Another is that people on this list and in the press are sloppy about security decisions that involve periods of time longer than about a year. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Has any public CA ever had their certificate revoked?
At 1:02 AM +1200 5/7/09, Peter Gutmann wrote: >Paul Hoffman writes: > >>Peter, you really need more detents on the knob for your hyperbole setting. >>"nothing happened" is flat-out wrong: the CA fixed the problem and researched >>all related problems that it could find. Perhaps you meant "the CA was not >>punished": that would be correct in this case. > >What I meant was that there were no repercussions due to the CA acting >negligently. We agree fully, then. >This is "nothing happened" as far as motivating CAs to exercise >diligence is concerned, you can be as negligent as you like but as long as you >look suitably embarassed afterwards there are no repercussions (that is, >there's no evidence that there was any exodus of customers from the CA, or any >other CA that's done similar things in the past). This assertion is probably, but unprovably, wrong. I suspect the CA now has better mechanisms in place to check for the problem in the future, and I suspect that a few other CAs seeing the kerfuffle probably added their own automated checks. Note that these are checks that should have been in place before the error was found. >Imagine if a surgeon used rusty scalpels and randomly killed patients, or a >bank handed out money to anyone walking in the door and claiming to have an >account there, or a restaurant served spoiled food, or ... . The >repercussions in all of these cases would be quite severe. However when >several CAs exhibited the same level of carelessness, they looked a bit >embarassed and then went back to business as usual. ...because not only did no one die, but also the CAs were able to fix the problem. >The CA-as-a-certificate- >vending-machine problem (or "rogue CA" if you want to call it that) had been >known for years (Verisign's "Microsoft" certificates of 2001 were the first >case that got widespread publicity) but since there are no repercussions for >CAs doing this there's no incentive for anything to change. s/no/small/ > >>This leads to the question: if a CA in a trust anchor pile does something >>wrong (terribly wrong, in this case) and fixes it, should they be punished? > >If a CA in a trust anchor pile does something terribly wrong and there are no >repercussions, why would any CA care about doing things right? Slight worry about making a more serious mistake than happened here. >All that does >is drive up costs. The perverse incentive that this creates is for CAs to >ship as many certificates as possible while applying as little effort as >possible. And thus we have the current state of commercial PKI. Fully agree. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Has any public CA ever had their certificate revoked?
At 6:44 PM -0400 5/5/09, Jerry Leichter wrote: >On May 5, 2009, at 1:17 PM, Paul Hoffman wrote: >>...This leads to the question: if a CA in a trust anchor pile does something >>wrong (terribly wrong, in this case) and fixes it, should they be punished? >>If you say "yes", you should be ready to answer "who will benefit from the >>punishment" and "in what way should the CA be punished" >The same question can be asked about *any* instance of criminal behavior, or >of any other kind of behavior that is considered "bad enough" to be worthy of >punishment. Tautologically so. >As for what your punishment as a "bad CA" should be: Realistically, in any >industry based on trust, the major component of punishment should be loss of >trust - which results in people refusing to do business with you any more, >which will usually put you out of business. Even with this definition, there was no significant punishment in this case. I'm not saying there should be, particularly because the CA cleaned things up fairly rapidly, but only a few people probably have reduced their trust of the CA in question. >In egregious cases, we send people to jail (where they can spend time with >Bernie Madoff). We also have mechanisms that aren't punishments but deal with >the equities of the situation: They try to right the wrongs. So if I can >show that your malfeasance as a CA led to my losing money, you have to >compensate me. That has never been shown in a case of CAs not following their stated procedures. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Has any public CA ever had their certificate revoked?
At 4:11 PM +1200 5/5/09, Peter Gutmann wrote: >Thierry Moreau writes: > >>Now that the main question is answered, there are sub-questions to be asked: >> >>1. Has any public CA ever encountered a situation where a revocation would >>have been necessary? > >Yes, several times, see e.g. the recent mozilla.org fiasco, as a result of >which nothing happened because it would have been politically inexpedient to >revoke the CA's cert. Peter, you really need more detents on the knob for your hyperbole setting. "nothing happened" is flat-out wrong: the CA fixed the problem and researched all related problems that it could find. Perhaps you meant "the CA was not punished": that would be correct in this case. This leads to the question: if a CA in a trust anchor pile does something wrong (terribly wrong, in this case) and fixes it, should they be punished? If you say "yes", you should be ready to answer "who will benefit from the punishment" and "in what way should the CA be punished". (You don't have to answer these, of course: you can just mete out punishment because it makes you feel good and powerful. There is lots of history of that.) --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Obama's secure PDA
At 2:49 AM -0500 1/26/09, Ivan Krstiç wrote: >There are still conflicting reports about whether the hardware is an altered >RIM BlackBerry or a different device, though the most likely contender for the >latter option appears to be the General Dynamics Sectéra Edge, which features >a "trusted [secondary] display" and two buttons used to switch between >classified and unclassified operation. Government Computer News says it is definitely not a BlackBerry. However, GCN's reporters aren't always as good as they should be (or even as good as the regular IT press) on getting their facts straight on security issues. <http://gcn.com/articles/2009/01/23/obama-gets-super-secure-smartphone.aspx> I too would like to hear more information on this, particularly the crypto that is known to be used on the Edge. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
At 1:38 PM + 1/19/09, Darren J Moffat wrote: >Can you state the assumptions for why you think that moving to SHA384 would be >safe if SHA256 was considered vulnerable in some way please. Sure. I need 128 bits of pre-image protection for, say, a digital signature. SHA2/256 is giving me that. Then, due to some weakness, it is only giving me 112 bits of protection. The weakness is understood in the crypto community, and it's a straight-line loss of bits of protection. SHA2/384 would then give me 168 bits of protection, which is more than the 128 what I need. Even if you don't trust that there is a straight-line loss of bits, you would have to be believing that the attack is much worse for SHA2/384 than it was for SHA2/256 in order to bring the output down to the level that I need. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow
At 12:24 PM +0100 1/12/09, Weger, B.M.M. de wrote: >When in 2012 the winner of the >NIST SHA-3 competition will be known, and everybody will start >using it (so that according to Peter's estimates, by 2018 half >of the implementations actually uses it), do we then have enough >redundancy? No offense, Benne, but are serious? Why would "everybody" even consider it? Give what we know about the design of SHA-2 (too little), how would we know whether SHA-3 is any better than SHA-2 for applications such as digital certificates? In specific, if most systems have implemented the whole SHA-2 family by the time SHA-3 is settled, and then there is a problem found in SHA-2/256, I would argue that it is probably much more prudent to change to SHA-2/384 than to SHA-3/256. SHA-2/384 will most likely be much than to SHA-3/256, but it will have had significantly more study. It all depends on who you trust and why. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
At 10:19 PM -0500 12/30/08, Jerry Leichter wrote: >Robert Graham writes in Errata Security >(http://erratasec.blogspot.com/2008/12/not-all-md5-certs-are-vulnerable.html) >that the attack depends on being able to predict the serial number field that >will be assigned to a legitimate certificate by the CA. That part is true. >Only a few CA's use predictable "serial numbers" That part, I think, is wrong. I looked into this a bit earlier this month and found that most of the ones I looked at are still using sequential numbers. >- the field is actually arbitrary text If by "arbitrary text" you mean "a non-negative integer". >and need only be certainly unique among all certificates issued by a given CA. True as well. >So: The current attack is only effective against a very small number of CA's >which both use MD5 *and* have predictable sequence numbers. The attack is on end users who trust a root store that has a trust anchor from *any single* CA that uses MD5 and has predictable sequence numbers. The attack lets the attacker become a subordinate CA for that CA. At that point, the attacker can issue their own certs for any purpose. >So the sky isn't falling It never does. That's why it is the sky. >- though given how hard it is to "decertify" a CA (given that the "known good" >CA's are known to literally billions of pieces of software, and that hardly >anyone checks CRL's - and are there even CRL's for CA's?) this is certainly >not a good situation. There are not CRLs for CAs. That's why is it is a root store. Oh, and how do you create a definitive list of CAs that use MD5 in their signatures? >This also doesn't mean that, now that the door has been opened, other attacks >won't follow. In fact, it's hard to imagine that this is the end of the >story Quite right. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: TLS Server Name Indication and IDNA?
RFC 4366 is somewhat of a mess. I do not remember the authors asking the authors of IDNA (of which I am one) about what they should do. FWIW, I'm not sure why this would be on the cryptography list, but I'm not sure of that for most of the "we can design a better UI" threads either. What should the SMTP client put in the RFC 4366 section 3.1 "HostName": - The ACE domain it is working with (xn--exmple-cua.com)? - The underlying UTF8 domain name? (exämple.com)? Hopefully, the former. But if that doesn't work, try the latter. What should the server do when it receives the client's "HostName"? - Convert ACE to UTF8? - Convert UTF8 to ACE? Hopefully, neither: leave it as an ACE. What type of comparison is the server expected to perform? - Convert UTF8 CommanName to ACE (also leave IA5 alone) and then compare? - Convert ACE names in either subjectAltName or CN to UTF8 and then compare UTF8 strings (with NAMEPREP, STRINGPREP and all that jazz)? Hopefully, neither: leave it as an ACE. This can be (to say the least) rather unpleasant. If IDNA is only between the user and the UI, with everything on the wire in ACE form, Yes. then all the pain is avoided: Yes+. That's why we designed IDNA that way. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "Cube" cryptanalysis?
At 11:08 AM -0700 8/21/08, Greg Rose wrote: Adi mentioned that the slides and paper will go online around the deadline for Eurocrypt submission; it will all become much clearer than my wounded explanations then. There now: <http://eprint.iacr.org/2008/385> --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: once more, with feeling.
At 11:21 PM +0100 9/9/08, Dave Howe wrote: Darren J Moffat wrote: Warnings aren't enough in this context [ whey already exists ] the only thing that will work is stopping the page being seen - replacing it with a clearly worded explanation with *no* way to pass through and render the page (okay maybe with a debug build of the browser but not in the shipped product). One thing that concerns me is that in the new release of firefox, there appears to be NO way to get to a site that has a bad certificate (or self signed certificate) other than overriding the warning permanently - no "ok let me see it, I have seen the warning and want to look just this once" that the "remember mismatched domains" plugin for 2.x gave you. That may concern you, but I consider it a feature. Instead of teaching users to "always click through the damn dialog boxes", FF3 says "if you fell for it once, you're going to always fall for it so we won't teach you bad habits". There are arguments for either strategy. Given that few or none of us on this list are actually trained interface experts, I'm sure we could debate this until Perry pulls the moderator switch again. The salient point is that people who have more stake in the game (Mozilla Inc.) have spent longer thinking about this than we give them credit for and come to the design decisions that they have. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: once more, with feeling.
At 4:16 PM +0100 9/8/08, Darren J Moffat wrote: Hopefully this is interesting enough to get forwarded on... Ditto. :-) Warnings aren't enough in this context [ whey already exists ] the only thing that will work is stopping the page being seen - replacing it with a clearly worded explanation with *no* way to pass through and render the page (okay maybe with a debug build of the browser but not in the shipped product). It depends on how we think change can be achieved. Until now, people designing pages using bad security practices balanced their laziness with the fact that their content would be displayed anyway so whatever. You are proposing moving to the other extreme. Given how easy your solution would be for browser vendors to implement, we have to assume that they have considered it and rejected it. A less extreme solution would be to make the warning the user sees on a mixed-content page more insulting to the bank. "This page contains both encrypted and non-encrypted content and is inherently insecure. The owner of this web site has clearly made a very poor security decision in showing this page to you. It is likely that other pages on this site also have similarly poor security. Knowing this, do you wish to continue anyway?" --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Voting machine security
At 9:24 AM -0700 8/18/08, Eric Rescorla wrote: (and because of the complexity of US elections, hand counting is quite expensive) This is quite disputable. Further, hand vs. machine counting is core to the way we think about the security of the voting system. On a "complex" ballot, there are maybe 20 races or propositions, some of which may allow multiple votes per race. The pre-electronic method for hand-counting these was to start with race #1, have one person reading each vote out load from a large stack of ballots, and another person tabulating. In most districts, this is done twice with different people doing the counting and, often, those people coming from the "opposite party" in our wonderful two-party system. The numbers I saw in the late 1970's said that each vote took 2.5 seconds per ballot per race when done slowly; so that's 5 seconds when run twice. Per "complex" ballot, that's about 100 seconds, or roughly 2 minutes, or roughly 1/30 of an hour. At current labor rates of $12/hour for this type of work (that's high, but we want qualified people to count), that means it costs about US$0.40 per ballot for a complex ballot. Essentially no one would argue that is is "quite expensive". I suspect that nearly everyone in the country would be happy to pay an additional $1/election for more reliable results. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
At 1:47 PM -0500 8/8/08, Nicolas Williams wrote: On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote: The kerberos style of having credentials expire very quickly is one (somewhat less imperfect) way to deal with such things, but it is far from perfect and it could not be done for the ad-hoc certificate system https: depends on -- the infrastructure for refreshing all the world's certs every eight hours doesn't exist, and if it did imagine the chaos if it failed for a major CA one fine morning. The PKIX moral equivalent of Kerberos V tickets would be OCSP Responses. I understand most current browsers support OCSP. ...and only a tiny number of CAs do so. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
At 4:27 PM +0200 7/14/08, Florian Weimer wrote: Implementors say that in many cases, their software as it's currently implemented can't take the load. It's not much worse than web traffic, that's why I think it can be made to work (perhaps easier with kernel support, who knows). But code changes are apparently required. That whole paragraph, taken together, makes no sense. And once you need code changes, you can roll out DNSSEC--or some extended query ID with 64 additional bits of entropy. There is a difference between code changes in the kernel for some systems (which you allude to above), code changes and a universal rollout in all DNS software (which you allude to at the end), and stable rollout of the DNSSEC trust anchor system in every significant zone and all resolvers. FWIW, only the latter has anything to do with this mailing list... --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the "Kaminsky finds" meme. Take a look at <http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/>. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that "Dan didn't discover the problem", but "Dan got it fixed". An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Upper limit?
At 8:46 PM -0700 7/4/08, Allen wrote: Is there an upper limit on the number of RSA Public/Private 1024 bit key pairs possible? If so what is the relationship of the number of 1024 bit to the number of 2048 and 4096 bit key pairs? On a related note: why did you skip 1536 bits? There is nothing special about key lengths being an integral power of 2 bits long. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Strength in Complexity?
At 12:48 AM +1200 7/6/08, Peter Gutmann wrote: Florian Weimer <[EMAIL PROTECTED]> writes: * Peter Gutmann: [1] Show of hands, how many people here not directly involved with X.509 work knew that the spec required that all extensions in CA root certificates ("trust anchors" in recent X.509 jargon) be ignored by an implementation? So if you put in name constraints, key usage constraints, a policy identifier, etc, then a conforming implementation is supposed to look at them, throw them away, and proceed as if they weren't there? Are you sure that the constraints are not supposed to be applied when the root certificate is actually processed, after its signature has been verified by the trust anchor? Yup. The app is supposed to read the cert, parse and process the extensions, and then throw them away. Peter: please turn down the hyperbole a bit. You forgot the word "may" between "and" and "then". The text from the spec is: 3.3.60 trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period. The trust anchor may be provided in the form of a self-signed certificate. A trust anchor is trusted by a certificate using system and used for validating certificates in certification paths. Rendered into English, that says "take the pubic key, owner name, and validity period, and ignore everything else in the cert". Wrong. There is no requirement to "ignore everything else in the cert". There is simply no requirement to use that material. To pre-empt the inevitable "yes, but it doesn't explicitly say you can't process the extensions if you want to": It also doesn't say you can't reformat the user's hard drive when you see a cert, but the intent is that you don't do anything not explicitly listed in the text above. No offense, but if I wanted to know the intent of a group of people who make hard-to-read-and-harder-to-impelemnt crypto standards, I would not ask you. You don't know their intent, Peter: you only know the output of the sausage-making process. If I haven't made it clear: I agree with Peter that the spec should have clearly stated what one was supposed to do with the extensions. Where I think we disagree is that I would rather that the spec said explicitly to throw them away. I would rather have the semantics of "this is what I say my name is and this is what I say my public key is" quite separate from "this is what I think you should trust me to authenticate". This adds complexity (it takes two certs), but it also reduces complexity (it doesn't mandate binding policy to identification). Luckily no sane implementation pays any attention to this nonsense :-). We might agree here because I don't think there are many sane implementations of X.509. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Strength in Complexity?
At 8:28 PM -0400 7/1/08, Perry E. Metzger wrote: [EMAIL PROTECTED] (Peter Gutmann) writes: "Perry E. Metzger" <[EMAIL PROTECTED]> writes: No. In fact, it is about as far from the truth as I've ever seen. No real expert would choose to deliberately make a protocol more complicated. IPsec. Anything to do with PKI. XMLdsig. Gimme a few minutes and I can provide a list as long as your arm. Protocol designers *love* complexity. The more complex and awkward they can make a protocol, the better it has to be. The problem, Peter, is that people who don't know you may mistake your sarcasm for agreement with misconception in the article Arshad quoted. The quote from the article was: "There are, of course, obstacles that must still be overcome by EKMI proponents. For example, the proposed components are somewhat simple by design, which concerns some encryption purists who prefer more complex protocols, on the logic that they're more difficult to break into." It jumps from "components" to "protocols". In general, "encryption purists" like simpler algorithms. OTOH, when "encryption purists" get involved in protocol design, the protocols usually become complex to the point of opacity. So, I agree with Peter that that article is probably correct about protocols. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Protection mail at rest
At 11:36 AM -0400 6/1/08, Ivan Krstiç wrote: The easiest thing for people who _do_ care is still running their own mail server. Fully agree. You're in control, all the way to root of the box. The emergence of reasonably priced VM hosting providers (e.g. slicehost.com) makes it fairly uncomplicated, modulo initial setup. And, if you want to host on FreeBSD instead of Linux, see <http://www.rootbsd.net/>. Same price, good service. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The perils of security tools
More interesting threadage about the issue here: <http://taint.org/2008/05/13/153959a.html>, particularly in the comments. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The perils of security tools
At 10:25 AM +0100 5/15/08, Ben Laurie wrote: Paul Hoffman wrote: I'm confused about two statements here: At 2:10 PM +0100 5/13/08, Ben Laurie wrote: The result of this is that for the last two years (from Debian's "Edgy" release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys. . . . [2] Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it. The second bit makes it sound like the stuff that the Debian folks blindly removed was one, possibly-useful addition to the entropy pool. The first bit makes it sound like the stuff was absolutely critical to the entropy of produced keys. Which one is correct? They removed _all_ entropy addition to the pool, with the exception of the PID, which is mixed in at a lower level. I take it that these are not 128-bit, non-monotonic PIDs. :-) The bigger picture is that distributions who are doing local mods should really have an ongoing conversation with the software's developers. Even if the developers don't want to talk to you, a one-way conversation of "we're doing this, we're doing that" could be useful. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The perils of security tools
I'm confused about two statements here: At 2:10 PM +0100 5/13/08, Ben Laurie wrote: The result of this is that for the last two years (from Debian's "Edgy" release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys. . . . [2] Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it. The second bit makes it sound like the stuff that the Debian folks blindly removed was one, possibly-useful addition to the entropy pool. The first bit makes it sound like the stuff was absolutely critical to the entropy of produced keys. Which one is correct? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SSL/TLS and port 587
At 9:49 PM -0800 1/22/08, Ed Gerck wrote: Can you point to some sources of this "often expressed idea"? It seems like a pretty flimsy straw man. It is common with those who think that the threat model is "traversing the public Internet". I'll take that as a "no". For examples on claiming that SSL/TLS can protect email privacy, That's not what I asked, of course. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SSL/TLS and port 587
At 10:38 AM -0800 1/22/08, Ed Gerck wrote: The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or protect any private communications, is IMO simply not supported by facts. Can you point to some sources of this "often expressed idea"? It seems like a pretty flimsy straw man. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Flaws in OpenSSL FIPS Object Module
At 9:58 AM -0500 12/3/07, Perry E. Metzger wrote: I don't know if people have been following this, but it is interesting from the point of view of studying how the FIPS process does (or does not) interact with the underlying goal of producing assured systems. Another interesting part is that open-source systems are much more susceptible to being attacked by competitors (that is, having their validation suspended) than are closed-source systems. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Fixing the current process
At 10:55 PM +0200 10/8/07, Ian G wrote: A slightly off-topic question: if we accept that current processes (FIPS-140, CC, etc) are inadequate indicators of quality for OSS products, is there something that can be done about it? Highly doubtful. The institutional inertia at DoD/NIST is too great. It has been suggested numerous times by numerous concerned parties for at least a decade. Is there a reasonable criteria / process that can be built that is more suitable? Yes. That part is easy, and some people in the system admit designing a much better system is quite tractable, as long as it is done in a vacuum. However, bureaucracy abhors a vacuum. My feeling is that the only way that we can overturn the silliness of FIPS-140 / CC is for a major defense ally to implement a sane system. Five years later, and with a lot of vendor push, it could become a third process and the other two could wither over the ensuing decades. If we're lucky. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: more SHA-1 progress?
At 10:17 AM -0400 8/22/07, Perry E. Metzger wrote: Ekr's blog notes a rumor that more progress has been made on attacking SHA-1: http://www.educatedguesswork.org/movabletype/archives/2007/08/sha1_rumors.html Anyone know anything about this? This is a continuation of the thread on this list from last week. I watched the webcast of the rump session, and Christian Rechberger said that they think they will get 2^60ish with a new technique. He did not describe the technique in any detail. Offline, he has told me that there will be papers published. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Re: Fwd: Potential SHA 1 Hack Using Distributed Computing - Near Miss(es) May be Good Enough
At 11:31 PM +0200 8/14/07, Christian Rechberger wrote: The mentioned article is indeed confusing, the information in there took apparently several hops. Welcome to the world of public cryptography! :-) At least I haven't seen anyone so far suggest that you will find pre-images. To address your questions: Indeed, we have our own "path", but more importantly we developed a new method to speed-up generation and testing of candidate message pairs and apply it to SHA-1. The resulting work factor is still quite high, hence we ask for contributions via the BOINC framework. Is there any estimation of how high? Specifically, do you believe there is a good chance of having less work effort than the current Wang strategy? For example, if you are sure that your result will be around 2^70, well that is interesting in theory but probably not worth any publicity you have gotten so far. If you are sure it will be around 2^55, I'll certainly give you some of my spare CPU cycles. More information on cryptanalytic details, type of collision, and resulting work factor will appear later this year. That's good to hear. It would also be interesting if you could keep a running meter of approximately how much work you are getting from the participants. This isn't nearly as "sexy" as finding ETs or even protein folding... --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Fwd: Potential SHA 1 Hack Using Distributed Computing - Near Miss(es) May be Good Enough
At 4:49 PM -0300 8/14/07, Mads Rasmussen wrote: Have a look at http://boinc.iaik.tugraz.at/sha1_coll_search Did that, in specific <http://www.iaik.tugraz.at/research/krypto/collision/SHA1Collision_Description.php> Note the lack of information about what they are actually doing. "We developed new cryptanalytic methods..." sounds great, but is meaningless without specifics. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Fwd: Potential SHA 1 Hack Using Distributed Computing - Near Miss(es) May be Good Enough
At 11:00 PM -0700 8/13/07, Aram Perez wrote: Anyone know more about this? I have the same question. I could not find any description of *why* they think that finding near-misses is going to help the research. It's not clear if they are taking their own path, or trying to improve Wang's path, or what. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
At 7:58 PM +1200 7/20/07, [EMAIL PROTECTED] wrote: Paul Hoffman <[EMAIL PROTECTED]> writes: At 2:45 AM +1200 7/20/07, [EMAIL PROTECTED] wrote: |From a security point of view, this is really bad. From a usability point of |view, it's necessary. As you can see from my list of proposed solutions, I disagree. I see no reason not to to alert a user *who has removed a root* that you are about to put it back in. It depends on what you mean by "user". You're assuming that direct action by the wetware behind the keyboard resulted in its removal. Correct, I was. However given how obscure and well-hidden this capability is, it's more likely that a user agent acting with the user's rights caused the problem. So the message you end up communicating to the user is: "Something you've never heard of before has changed a setting you've never heard of before that affects the operation of something you've never heard of before and probably wouldn't understand no matter how patiently we explain it". (those things are, in order "some application or script", "the cert trust setting", "certificates", and "PKI"). Very good point. Bigger picture takeaway: when both a user and an application can change a crypto setting in an application (or OS), any later messages relating to that event are likely to be confusing because they can't be directly linked to the action. This applies to all of our crypto-in-the-real-world, not just the trust anchor issue at hand. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
At 2:45 AM +1200 7/20/07, [EMAIL PROTECTED] wrote: From a security point of view, this is really bad. From a usability point of view, it's necessary. As you can see from my list of proposed solutions, I disagree. I see no reason not to to alert a user *who has removed a root* that you are about to put it back in. Note that I did not criticize the practice of starting with a zillion roots that Microsoft trusts. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
New article on root certificate problems with Windows
Hi again. I posted a new security research article at <http://www.proper.com/root-cert-problem/>. It is not directly related to crypto (although not so much of the traffic on this list is...), it does relate to some PKI topics that are favorites of this list. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Quantum Cryptography
At 5:11 PM -0400 7/2/07, John Denker wrote: By that I mean: -- the integrity of DH depends fundamentally on the algorithm, so you should verify the algorithmic theory, and then verify that the box implements the algorithm correctly; while -- in the simple case, the integrity of quantum cryptography depends fundamentally on the physics, so you should verify the physics theoretically and then verify that the box implements the physics correctly, ... and not vice versa. This is a nice, calm analogy, and I think it is useful. But it misses the point of the snake oil entirely. The fact that there is some good quantum crypto theory doesn't mean that there is any application in the real world. For the real world, you need key distribution. For the cost of a quantum crypto box (even after cost reductions after years of successful deployment), you could put a hardware crypto accelerator that could do 10,000-bit DH. Going back to the theory, the only way that quantum crypto will be more valuable than DH (much less ECDH!) is if DH is broken *at all key lengths*. If it is not, then the balance point for cost will be when the end boxes for quantum crypto equals the cost of the end boxes for still-useful DH. Oh, and all the above is ignoring that DH works over multiple hops of different media, and quantum crypto doesn't (yet, maybe ever). --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
At 3:26 PM -0500 6/26/07, Nicolas Williams wrote: I strongly dislike the WG's name. Suffice it to say that it was not my idea :); it created a lot of controversy at the time, though perhaps that controversy helped sell the idea ("why would you want this silly, insecure stuff?" "because it enables this other actually secure stuff"). Whereas I was in the camp of liking the name very much for the very reason that this thread was started: "because it lets you encrypt an arbitrary conversation with essentially no startup cost". --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
At 2:49 PM -0500 6/26/07, Nicolas Williams wrote: On Fri, Jun 22, 2007 at 10:43:16AM -0700, Paul Hoffman wrote: > This was discussed many times, and always rejected as "not good enough" by the purists. Then the IETF created the BTNS Working Group which is spending huge amounts of time getting close to purity again. That's pretty funny, actually, although I don't quite agree with the substance (surprise!) :) Why, are you some sort or purist? :-) (For those outside the IETF, Nico is one of the main movers and shakers in BTNS, and is probably one of the main reasons it looks like it will actually finish its work.) Seriously, for those who merely want unauthenticated IPsec, MITMs and all, then yes, agreeing on a globally shared secret would suffice. Well, almost suffice. You also need a way of signalling before the Diffie-Hellman that this is what you are doing, but that's a trivial extension to both IKEv1 and IKEv2. For all the other aspects of BTNS (IPsec connection latching [and channel binding], IPsec APIs, leap-of-faith IPsec) agreeing on a globally shared secret does not come close to being sufficient. Fully agree. BTNS will definitely give you more than just one-off encrypted tunnels, once the work is finished. But then, it should probably be called MMTBTNS (Much More Than...). --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Quantum Cryptography
At 10:44 AM -0700 6/22/07, Ali, Saqib wrote: ...whereas the key distribution systems we have aren't affected by eavesdropping unless the attacker has the ability to perform 2^128 or more operations, which he doesn't. Paul: Here you are assuming that key exchange has already taken place. No, I'm not. I am talking about protocols that do their own key exchange. IPsec. SSL/TLS. Kerberos. Etc. But key exchange is the toughest part. No, requiring that the two ends have a fixed connection which QKD works over is far tougher than using a proven protocol that works over any connection. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
At 11:52 PM +0800 6/22/07, Sandy Harris wrote: On 6/22/07, Eugen Leitl <[EMAIL PROTECTED]> wrote: So what's the state in ad hoc IPsec/VPN setup for any end points? The Linux FreeS/WAN project was working on "opportunistic encryption". The general idea is that if you use keys in DNS to authenticate gateways and IPsec for secure tunnels then any two machines can communicate securely without their administrators needing to talk to each other or to set up specific pre-arranged tunnels. http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/glossary.html#carpediem http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html There is an RFC based on that work: ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt The FreeS/WAN project has ended. I do no know if the follow-on projects, openswan.org and strongswan.org, support OE. Note that that RFC is Informational only. There were a bunch of perceived issues with it, although I think they were more purity disagreements than anything. FWIW, if you do *not* care about man-in-the-middle attacks (called active attacks in RFC 4322), the solution is much, much simpler than what is given in RFC 4322: everyone on the Internet agrees on a single pre-shared secret and uses it. You lose any authentication from IPsec, but if all you want is an encrypted tunnel that you will authenticate all or parts of later, you don't need RFC 4322. This was discussed many times, and always rejected as "not good enough" by the purists. Then the IETF created the BTNS Working Group which is spending huge amounts of time getting close to purity again. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Quantum Cryptography
At 10:59 AM -0700 6/21/07, Ali, Saqib wrote: - Quantum Cryptography is "fiction" (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). Well that is a broad (and maybe unfair) statement. Quantum Key Distribution (QKD) solves an applied problem of secure key distribution. It may not be able to ensure "unconditional" secrecy during key exchange, but it can detect any eavesdropping. Once eavesdropping is detected, the key can be discarded. ...whereas the key distribution systems we have aren't affected by eavesdropping unless the attacker has the ability to perform 2^128 or more operations, which he doesn't. Which part of the word "useless" is not apparent here? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
SSL certificates for SMTP
At 6:34 PM +0200 5/23/07, Florian Weimer wrote: * Victor Duchovni: That's good of you not to expect it, given that zero of the major CAs seem to support ECC certs today, and even if they did, those certs would not work in IE on XP. We are not talking about this year or next of course. My estimate is that Postfix releases designed this year, ship next year, are picked up by some O/S vendors the year after and shipped perhaps a year after that, then customers take a few years to upgrade, ... So for some users Postfix 2.5 will be their MTA upgrade in 2011 or later. So we need to anticipate future demand by a few years to be current at the time that users begin to use the software. But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). No one? I thought that VeriSign and others did, at least a few years ago. As far as I know, there isn't even a way to store mail routing information in X.509 certificates. Why would you need to? SMTP-over-TLS only identifies the system to whom you are speaking. No routing inforation is needed or wanted. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: 307 digit number factored
For the math weenies on the list, see the full announcement here: <http://listserv.nodak.edu/cgi-bin/wa.exe?A2=ind0705&L=nmbrthry&T=0&P=1019>. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: 307 digit number factored
FWIW, according to Arjen Lenstra, there should be a better paper than the physorg.com article on the eprint.iacr.org site next week, hopefully. At 4:32 PM -0400 5/21/07, Victor Duchovni wrote: When do the Certicom patents expire? Which ones? They have many. Using EC depends on how brave you are and which country you are in. I really don't see ever longer RSA keys as the answer, and the patents are I think holding back adoption... Because I agree with the latter, I disagree with the former, at least for a few more years and until a few people are braver than I am. The other issue is that sites will need multiple certs during any transition from RSA to ECC, because the entire Internet won't upgrade overnight. I am not expecting public CAs to cooperate by charging the same price for two certs (RSA and ECC) for the same subject name(s), this also may significantly impede migration. That's good of you not to expect it, given that zero of the major CAs seem to support ECC certs today, and even if they did, those certs would not work in IE on XP. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
At 6:34 PM + 5/20/07, John Levine wrote: >I've heard nothing formal, but my strong understanding is a lot of US government machines, at least if we're talking workstations on non-classified nets, are in fact "0wn3d" at this point. Well, here's an anecdote: at last year's CEAS conference, Rob Thomas of Team Cymru gave the keynote on the underground economy, with a most horrifying set of both live demos and selected snapshots of the online bazaars where online warez are traded, everything from zombie farms to spamware to stolen credit cards. One of the more amusing was a guy who offered a zombie in some part of the government that you'd hope would be moderately secure, NASA or someplace like that, at a higher than normal price. The immediate response was ridicule, bots on government nets are a dime a dozen, and aren't worth any more than any other bot. Oh, goodie. I get to the same source to show the opposite. At Rob's talk at the AOTA summit, he talked about someone offering some botted machines in a particular US government subnet at a normal prices and someone quickly over-bid by a suspiciously high amount. The assumption is that it was for the possible data on those machines. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: 128 bit number T-shirt?
At 8:59 PM -0400 5/1/07, Perry E. Metzger wrote: [Moderator's note: Manually forwarded because of a software glitch. --Perry] From: Gary Ellison <[EMAIL PROTECTED]> Subject: Re: 128 bit number T-shirt? To: "Perry E. Metzger" <[EMAIL PROTECTED]> CC: cryptography@metzdowd.com Date: Tue, 01 May 2007 17:30:10 -0700 Your wish has been granted http://www.cafepress.com/09f9 This would be a lot more popular if the t-shirt and mug said something a bit more fetching above the hex such as "Ask me about HD-DVD". - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
At 2:04 PM -0700 4/21/07, David Wagner wrote: Hagai Bar-El writes: What Aram wrote is "many of the attendees have very little security experience", not: "there are no attendees with security experience". There are people at the relevant OMA group who know enough about security, but just like in the real world -- they are outnumbered by plain "feature-set" people, and thus have to come up with very clear arguments to get their way. So the people who don't know anything about security are reluctant to listen to those who do? That's not a good sign. It may be standard operating procedure in groups like this, but that doesn't make it right. It's still dysfunctional and dangerrous. If the committee doesn't have a commitment to security and is reluctant to listen to the experts, that's a risk factor. In a typical standards-setting environment, non-security people are usually only willing to listen to security people up to a certain threshold. There are three normal scenarios: - A security person proposes a good way to do security for the proposed protocol. A non-security person says (incorrectly) "I heard that doesn't work". The security person argues that it does work here, and the non-security person, not wanting to look foolish, digs in his heels. People get bored of hearing an argument they don't understand and make an arbitrary decision. - A non-security person proposes a bad way to do security for the proposed protocol. A security person explains why that is insecure. The non-security person argues (sometimes correctly) that they did it in this other protocol so we should copy that, and the security person tries to explain why this is bad security. People get bored of hearing an argument they don't understand and make an arbitrary decision. - A security person proposes two different ways to do security for the proposed protocol. The second is significantly faster than the first, but has worse security properties. People say "the first is good enough for our scenario" and pick it, often not even bothering to document the diminished security properties. FWIW, this can happen when designing pure security protocols, swapping "non-security person" with "security novice" or "security tourist" or "security hobbiest" or "security poser". So why do people with no training in security think that they can freely ignore the advice of security professionals without any negative consequences? Because doing so can get things finished earlier and/or make a more efficient protocol. Same as it ever was. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
[[ Agree with Nico's MITM arguments; different point below ]] At 10:49 AM -0500 4/6/07, Nicolas Williams wrote: The DHS would get real value in terms of veto power over new TLDs, IFF it is the only one to possess the root private key. But that's not what the story said, IIRC. Whoever owns the root key would only get to veto the inclusion of new or current TLDs in the DNSSEC-protected namespace, not in the root itself. No one expects that ICANN will be signing the zone keys for most of the TLDs for many, many years, if for no other reason than those TLDs don't even want to be responsible for protecting their zone key. The real problem with DHS having these keys in _addition_ to ICANN is that the more fingers in the pie the more likely it is that the key will be breached, leading to key rollover. Fully agree. It also means that, if there is a breach, the first few days / months will be spent finger-pointing instead of fixing. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
At 7:54 PM -0400 4/5/07, Thor Lancelot Simon wrote: On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote: >because, with it, one can sign the appropriate >chain of keys to forge records for any zone one likes. If the owner of any key signs below their level, it is immediately visible to anyone doing active checking. The root signing furble.net instead of .net signing furble.net is a complete giveaway to a violation of the hierarchy and an invitation for everyone to call bullshit on the signer. Doing so would completely negate the value of owning the root-signing key. You're missing the point. The root just signs itself a new .net key, and then uses that to sign a new furble.net key, and so forth. No unusual key use is required. And you seem to be missing my point. If the root signs itself a new .net key, it will be completely visible to the entire community using DNSSEC. The benefit of doing so in order to forge the key for furble.net (or microsoft.com) will be short-lived, as will the benefit of owning the root key. It's a hierarchy of trust: if you have the top, you have it all, and you can forge anything you like, including the keys used to sign the application key records used to encrypt user data, where they are present in the system. The only reason for concern is if the top of the hierarchy can forge without people noticing, or if people notice that they won't care. I claim that that isn't possible, particularly if the root owner is someone as unloved as USDHS. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
At 7:26 PM -0400 4/5/07, Thor Lancelot Simon wrote: On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote: Control: The root signing key only controls the contents of the root, not any level below the root. That is, of course, false, This is, of course false. In order to control the contents of the second level of the DNS, they have to either change the control of the first level (it's kinda obvious when they take .net away from VeriSign) or they have to sign across the hierarchy (it's kinda obvious when furble.net is signed by someone other than .net). and presumably is _exactly_ why DHS wants the root signing key: Um, since when are you (or I) so good at figuring out what DHS wants? For that matter, assuming that a massive bureaucracy like DHS has one thing that it wants also seems silly. For all we know, this could be one clue-deprived dork who can write press releases after not really listening to the one technical person whom he asked. Or it could be a conspiracy to take over the Department of Commerce. Or ... because, with it, one can sign the appropriate chain of keys to forge records for any zone one likes. If the owner of any key signs below their level, it is immediately visible to anyone doing active checking. The root signing furble.net instead of .net signing furble.net is a complete giveaway to a violation of the hierarchy and an invitation for everyone to call bullshit on the signer. Doing so would completely negate the value of owning the root-signing key. Plus, now that applications are keeping public keys for services in the DNS, one can, in fact, forge those entries and thus conduct man in the middle surveillance on anyone dumb enough to use DNS alone as a trust conveyor for those protocols (e.g. SSH and quite possibly soon HTTPS). ...again assuming that the users of those keys don't bother to look who signed them. Given that this thread is about an entity whom almost no one trusts being the key holder, that scenario seems unlikely. I know you understand this stuff well enough to know these risks exist. I'm curious why you'd minimize them. Because I believe that ISPs, not just security geeks, will be vigilant in watching whether there is any layer-hopping signing and will scream loudly when they see it. AOL and MSN have much more to lose if DHS decides to screw with the DNS than anyone on this list does. Having said that, it is likely that we will be the ones to shoot the signal flares if DHS (or ICANN, for that matter) misuses the root signing key. But it won't be us that causes DHS to stand down or, more likely, get thrown off the root: it's the companies who have billions of dollars to lose if the DNS becomes untrusted. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
At 5:51 PM +0100 4/4/07, Dave Korn wrote: Can anyone seriously imagine countries like Iran or China signing up to a system that places complete control, surveillance and falsification capabilities in the hands of the US' military intelligence? No. But how does having the root signing key allow those? Control: The root signing key only controls the contents of the root, not any level below the root. Surveillance: Signing keys don't permit any surveillance. Falsification: This is possible but completely trivially detected (it is obvious if the zone for furble.net is signed by . instead of .net). Doing any falsification will cause the entire net to start ignoring the signature of the root and going to direct trust of the signed TLDs. Surely if this goes ahead, it will mean that DNSSEC is doomed to widespread non-acceptance. More than it is now? And unless it's used everywhere, there's very little point having it at all. Fully disagree. Many ISPs and individuals will be happy to do direct trust of the significant zones (com/net/org plus maybe their local ccTLD) and simply ignore signatures on the rest. This has already been well-discussed in the ISP community even before this event: many are not sure they trust ICANN itself, much less its current "sponsor". Note that I'm not supporting the US signing the root in the least. I'm just saying that predicting doom is grossly premature. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: more on NIST hash competition
At 9:30 PM +1300 1/25/07, Peter Gutmann wrote: =?UTF-8?B?SXZhbiBLcnN0acSH?= <[EMAIL PROTECTED]> writes: Perry E. Metzger wrote: http://www.csrc.nist.gov/pki/HashWorkshop/index.html I'm completely unfamiliar with the way NIST operates, but I've been wondering for years why they haven't organized this competition already. Do we have a list veteran who can shed some light on why it took them this long? My curiosity demands to know. The AES competition was already a severe resource drain, running another one for an AHS would have been prohibitive, until the clear signs that SHA was in real trouble made it more palatable. This is an incorrect interpretation, I believe. The NIST folks at the workshop said a few times that they were not worried about SHA-1 because they have already deprecated it beginning at the end of 2010. That leaves only SHA-2, in which they said they had sufficient confidence. Further, no one publicly expressed worry at the workshop that SHA-2 would have any significant breaks in the near future. The dates on the competition timeline shows that AHS (cute name, Peter!) is not meant as a replacement for SHA-2, given that it won't be selected until after SHA-1 needs to stop being used. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: more on NIST hash competition
At 8:22 PM -0500 1/23/07, Ivan Krstiç wrote: Perry E. Metzger wrote: http://www.csrc.nist.gov/pki/HashWorkshop/index.html I'm completely unfamiliar with the way NIST operates, but I've been wondering for years why they haven't organized this competition already. Do we have a list veteran who can shed some light on why it took them this long? My curiosity demands to know. At the Second Hash Workshop this summer, NIST explained this a bit. (There were a bunch of regulars from this list there who can correct me if I'm wrong.) First, there is SHA-2 (SHA-256, -384, and -512). Nearly everyone thinks they are good enough unless there is an unexpected attack. So NIST was not hot to create something that competes with this. More important, however, is the lack of sureness in the community that we know what will make a good hash function, much less one that is better than SHA-2. See <http://www.proper.com/lookit/hash-futures-panel-notes.html> for much more on that. Also, remember that we don't know much about the design of SHA-2. In fact, unless the NSA tells the world a whole lot more, it will not be able to compete in the NIST competition due to requirement B1 in the proposal. At the end of the workshop, there were at least two camps: those who wanted a competition in case Wang-esque attacks degrade SHA-2, and those who didn't want a competition until we knew more about how to judge it because we don't know enough now. Some of the Big Names In Crypto are in the second group. It looks like NIST sided with the first group, but it will be interesting if the folks in the second group are vocal during the coming few years. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SC-based link encryption
At 7:58 PM -0800 1/3/07, Steve Schear wrote: I haven't been following the smartcard scene for a while. I'm looking to create a low-cost and portable link encryptor, with D-H or similar key exchange, for lower <100kbps data speeds. Is this possible? You could take an IPsec stack and repurpose it down one layer in the stack. At least that way you'll know the security properties of what you create. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
At 8:15 PM -0500 12/21/06, Saqib Ali wrote: Assuming that the two products use Internet protocols (as compared to proprietary protocols): I don't understand this statement. What do you mean by internet protocol vs proprietary protocol??? Now seeing what your company does, I can see where you might have that question. An overly-simple but sufficient answer comes from whether or not you need to be able to interoperate with other vendors over a non-secured network. If so, call it an "internet protocol". In your case (local disk encryption), it is fine to be proprietary. And also we are looking at FDE solutions, so there are no internet protocols involved in that. Right. no. Probably the only thing that could differentiate the two is if the cheaper one has a crappy random number generator, the more expensive one will have a good one. well I think FIPS 140-2 Level 1 ensures more than just a good PRNG. Even if a public crypto (e.g. AES) is used in a product, there are many mistakes that can be made during the implementation. ... and essentially all of those mistakes are caught by even mild interop testing. Again, this is not valid in your case. You could completely mis-implement AES and never know it, but a FIPS 140-2 test would find that. And FIPS 140-2 Level 1 is expected to catch these egregious mistakes. You can catch such mistakes for a lot less money than it will cost for a FIPS certificate. Assuming that you are using a standard encryption algorithm like AES, there are probably a dozen people on this mailing list who could sanity check your product's implementation of AES (and probably even of key storage) in less than 50 hours of consulting time, --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
At 11:25 AM -0500 12/21/06, Saqib Ali wrote: I would like to know how much weight people usually give to the FIPS 140-2 Level 1 certification. US federal agencies are supposed to require that certification for any system they buy that uses crypto. Sometimes, US state agencies require it as well. Sometimes, clueless corporations require it because it has the word "certification" in it and, well, if it's good enough for the feds, it should be good enough for everyone. If two products have exactly same feature set, but one is FIPS 140-2 Level 1 certified but cost twice. Would you go for it, considering the Level 1 is the lowest. Assuming that the two products use Internet protocols (as compared to proprietary protocols): no. Probably the only thing that could differentiate the two is if the cheaper one has a crappy random number generator, the more expensive one will have a good one. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: signing all outbound email
At 7:02 AM +1000 9/8/06, James A. Donald wrote: I do not seem to be able to use DKIM to for spam filtering. Correct. It is for white-listing. It tells the recipient (MTA or MUA) that the message received was sent from the domain name it says it was, and that parts of the message were not altered. I would like to whitelist all validly signed DKIM from well known domains. Good; that's what the protocol is designed to do. One way of doing this would be for the MTA to insist on a valid signature when talking to certain well known MTAs, and then my MUA could whitelist mail sent from those well known MTAs Yes, if you are willing to throw out messages whose signatures are broken during transit. (This is the same risk that others face with insisting on valid S/MIME or OpenPGP signatures be on every message from particular parties.) In short, I am not able to get any advantage out of using this protocol, which means that there is no advantage in sending me signed mail. And there is no disadvantage either. There is advantages for sending signed mail to users who have a different threat model than you have, and there are certainly administrative advantages to signing all outgoing mail, not looking to see "oh, if it is James, don't sign it because he won't like it". --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: signing all outbound email
At 11:40 AM +0200 9/5/06, Massimiliano Pala wrote: Jon Callas wrote: On 4 Sep 2006, at 4:13 AM, Travis H. wrote: Has anyone created hooks in MTAs so that they automagically [...] Go look at <http://www.dkim.org/> for many more details. This approach is MTA-to-MTA... No, it's not. The receiving MTA *and/or* MUA can verify signatures. That is clearly covered in the protocol document. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Phil Zimmerman and voice encryption; a Skype problem?
At 10:19 AM -0400 5/22/06, Steven M. Bellovin wrote: There's an article in today's NY Times (for subscribers, it's at http://www.nytimes.com/2006/05/22/technology/22privacy.html?_r=1&oref=slogin ) on whether Phil Zimmerman's Zfone -- an encrypted VoIP package -- will invite government scrutiny. There doesn't seem to be any imminent threat in the U.S.; the one concrete example mentioned -- the British plan to give police the power to compel individuals to disclose keys -- doesn't threaten Zfone, because it uses Diffie-Hellman for (among other things) perfect forward secrecy and doesn't even have any long-term keys. (See draft-zimmermann-avt-zrtp-01.txt for protocol details.) The fascinating thing, though, was this sentence near the end of the article: But at a conference last week in Cyprus, German officials said they had technology for intercepting and decrypting Skype phone calls, according to Anthony M. Rutkowski, vice president for regulatory affairs and standards for VeriSign, a company that offers security for Internet and phone operations. The Berson report says that Skype uses AES-256. NSA rates that as suitable for Top Secret traffic, so it's presumably not the cipher. Berson analyzed a number of other possible attack scenarios; the only one that seems to be possible is an active attack plus forged certificates. If Berson's analysis was correct -- and we all know how hard it is to verify cryptographic protocols -- that leaves open the possibility of a protocol change that implemented some sort of Clipper-like functionality. Please don't forget that the VeriSign spokesperson may be mistaken, or purposely lying (possibly in order to drum up business for the company). Neither would be a first for VeriSign. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
At 5:59 PM -0500 2/24/06, John Kelsey wrote: What we ultimately need is encryption and authentication that are: a. Automatic and transparent. b. Add some value or are bundled with something that does. c. Don't try to tie into the whole horrible set of PKI standards in terms of uniquely identifying each human and bit in the universe, and getting them to sign legally binding messages whose full interpretation requires reading and understanding a 30-page CPS. We have the preamble and (a) already; the problem is that the preamble is insufficient. What we ultimately need is encryption and authentication *and validation of the authentication* that match at least (a). Currently, it is the validation of the authentication that makes most users uninterested. When you get a message from Bob that comes with a warning that says "I cannot tell whether or not Bob really sent this", but you are sure that Bob actually sent that (due to some out-of-band knowledge), you lose faith in the system. When Bob has the same problem with your messages, you give up. For signed personal mail, (b) and (c) may be mutually exclusive. Why sign your messages if you don't want to be held liable for their contents? How can you get the reward of integrity without the cost of responsibility? Given those two hurdles, my hopes for authenticated mail near zero. I have some hopes for authenticated syndicated messages through Atom or RSS, but not this year. The hardest part there will be (c), but there are many environments where signing one-way mail is quite appropriate, particularly in replacing paper messages. The demand for encryption of personal email is perpetually low. Without a legal requirement, it will probably always be a small niche market. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
At 3:29 PM +0100 2/24/06, Philipp Gühring wrote: > Phil *does* have a problem with key management. He knows how to do it, but his communications partners are not as good as he is. Phil Z doesn´t know how to do it himself, at least with PGP. He told me that he doesn´t sign people´s keys who ask for it, simply because it would pollute his keyring on his computer, and he couldn´t work with a keyring with thousands of people on it anymore. It is a bit harsh to equate "doesn't want to do it because of the hassle" with "doesn't know how to do it". This is my original disagreement with Ed's message. It can be done, and when you do it it works, but it is too difficult for most people to bother with. I think we all agree on those three facts, just not on what to label the last one. So PGP obviously has a usability and scalability problem. Fully agree, and I would certainly extend that to S/MIME as well. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
At 4:31 PM -0800 2/23/06, Ed Gerck wrote: Usability should by now be recognized as the key issue for security - Fully agree. namely, if users can't use it, it doesn't actually work. We disagree on the meaning of the phrase "actually work". And what I heard in the story is that even savvy users such as Phil Z (who'd have no problem with key management) don't use it often. Phil *does* have a problem with key management. He knows how to do it, but his communications partners are not as good as he is. BTW, just to show that usability is king, could you please send me an encrypted email -- I even let you choose any secure method that you want. Yes, I could. But I won't bother. :-) --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
At 1:56 PM -0800 2/23/06, Ed Gerck wrote: This story (in addition to the daily headlines) seems to make the case that the available techniques for secure email (hushmail, outlook/pki and pgp) do NOT actually work. That's an incorrect assessment of the short piece. The story says that it does actually work but no one uses it. They briefly say why: key management. Not being easy enough to use is quite different than "NOT actually working". --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: general defensive crypto coding principles
At 5:40 PM + 2/12/06, Ben Laurie wrote: It also defends against the MD5 crack, and is one of the recommended IETF solutions to hash problems. s/recommended/proposed/ The IETF has not recommended any "solutions to hash problems". The sense of the room at the Hash BOF and the SAAG discussion at the Paris IETF meeting was that the IETF should *not* propose solutions to the problem. That is why the BOF did not turn into a Working Group and why there has been little discussion of the proposed solutions in the relevant IETF working groups. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: crypto wiki -- good idea, bad idea?
At 9:57 AM -0600 12/12/05, Travis H. wrote: Would a wiki specifically for crypto distribute the burden enough to be useful? Or should we just stick to wikipedia? Is it doing a satisfactory job? I cannot answer the first question: I am leery of wikis that have open posting rights, and I am leery of trusting anyone to maintain the posting rights and document quality of a wiki without being paid (either in money or whuffie) to do so. The second and third questions can be answered with "no". Someone wrote a fairly poor article on VPNs. That article has been flagged as needing a lot of work. I proposed a few weeks ago (in the meta-discussion) to do it, but was concerned that doing so would step on toes and seem invasive. No one has responded to that, not even the people who flagged the article as needing work. In other words, Wikipedia is trying to correct problems, but doesn't have the personpower to do so in a predictable fashion. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RNG implementations and their problems
At 10:54 PM -0600 12/3/05, Travis H. wrote: I'm dissatisfied with the state of /dev/random devices on Unix. Depends on what you mean by "Unix". FreeBSD 5 and 6 have much of what you want. So far I haven't seen any userland tools for updating the entropy count. From 'man 4 random': If the device has is using the software generator, writing data to random would perturb the internal state. This perturbation of the internal state is the only userland method of introducing extra entropy into the device. If the writer has superuser privilege, then closing the device after writing will make the software generator reseed itself. This can be used for extra security, as it immediately introduces any/all new entropy into the PRNG. The entropy harvesting and estimation code is bound too tightly to the entropy pool. It is in kernelspace so cannot do floating point, like measuring chi-square or Shannon entropy to estimate the amount of randomness. The software random device may be controlled with sysctl(8). To see the devices' current settings, use the command line: sysctl kern.random which results in something like: kern.random.sys.seeded: 1 kern.random.sys.burst: 20 kern.random.sys.harvest.ethernet: 0 kern.random.sys.harvest.point_to_point: 0 kern.random.sys.harvest.interrupt: 0 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 100 kern.random.yarrow.slowthresh: 160 kern.random.yarrow.slowoverthresh: 2 (These would not be seen if a hardware generator is present.) All settings are read/write. Thus, you can do your own calculations and change the paramters to your heart's content (assuming you have root privs). (...Other Linux-specific complaints elided...) --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Clips] Banks Seek Better Online-Security Tools
At 11:05 PM -0500 12/2/05, [EMAIL PROTECTED] wrote: You know, I'd wonder how many people on this list use or have used online banking. To start the ball rolling, I have not and won't. I have, and it's nice for making Quicken data entry faster, but that's about all. The rest gives me the willies when I see the security clue of the folks running the site. FWIW, I have never had a problem changing my password to something very long and all-alphabetic, even if I don't include "at least one capital letter and one digit" or whatever the CYA rules for passwords are these days. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: from the bad idea department
At 11:35 AM -0500 11/21/05, Steven M. Bellovin wrote: https://www.grc.com/passwords if you want to see more. (In fairness, the "Application Notes" section is listed as "under construction". Maybe it will contain suitable caveats when it's finished.) A different approach would be for him to write an open-source program that generates the passwords on your local machine. Of course, if it is distributed as an executable, you don't know if the executable is the same as the source, but you are already trusting him now on the program on his web site. Given that most users of this would be Windows folks, one could possibly write a really creative batch program to do this, thus eliminating the worry about the difference in executable. It would be mostrously ugly, but a nice hack. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "ISAKMP" flaws?
At 11:15 PM +1300 11/20/05, Peter Gutmann wrote: Unless you're the one paying someone $200/hour for it. Exactly. It prevents organizations who want security but cannot afford someone who understands it well from using IPsec. Optimally, someone should be able to say little more than "I want to do strong crypto and make a network with that guy over there; he will trust this ID and I will trust that ID; do it". That is not possible now. It is arguable that it isn't doable with SSL/TLS, either, but it's a heck of a lot closer there than in IPsec. Somehow I suspect that this (making it so unworkable that you have to hand- carry configuration data from A to B) wasn't the intention of the IKE designers :-). Correct. When the IETF was designing IKEv2 after seeing what real-world deployments of IKEv1 were causing, it was pointed out that this is not a "negotiation" but really "the responder always picks". Therefore, there was a suggestion that instead of having all this pre-arranged setup, we do "ask the responder what he wants", which is much simpler. We rejected that idea early on for (IMHO) bad reasons. On the other hand, no other widely-deployed security protocol seems to have made this leap of understanding either. It's not just the keying data though, it's all configuration information. Exactly. You can always tell a user "pick crypto suite A" and they can figure it out. Imagine telling them "figure out the network topology you want the other side to see, then figure out the network topology you expect to see, then write them down exactly". One networking guy spent some time over dinner recently describing how, when he has to set up an IPsec tunnel where the endpoints aren't using completely identical hardware, he uses a hacked version of OpenSWAN with extra diagnostics enabled to see what side A is sending in the IKE handshake, then configures side B to match what A wants. It is easier than that: just use Ethereal. It decodes the first four packets just fine. Once that's done, he calls A and has a password/key read out over the phone to set up for B. How does he fit his sneakers over the phone? :-) --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "ISAKMP" flaws?
At 11:20 AM +0100 11/17/05, Florian Weimer wrote: These bugs have been uncovered by a PROTOS-style test suite. Such test suites can only reveal missing checks for boundary conditions, leading to out-of-bounds array accesses and things like that. In other words, trivial implementation errors which can be easily avoided using proper programming tools. Which "proper programming tools" would check for a logic path failure when a crafted packet includes Subpacket A that is only supposed to be there when Subpacket B is there, but the packet doesn't include Subpacket B? There are no programming tools that check for this, or for related issues: it has to be the implementer who has enough understanding of the protocol and enough time (and program space) to code against such issues. Throw in PKIX certificates in certificate chains, and it gets much worse. IKE is a very complicated protocol with many within-packet and within-stream dependencies. These cannot be resolved by "proper programming tools" unless those tools are specifically crafted for IKE. SSL/TLS probably suffers the same fate. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "ISAKMP" flaws?
At 2:29 PM -0500 11/15/05, Steven M. Bellovin wrote: I mostly agree with you, with one caveat: the complexity of a spec can lead to buggier implementations. Well, then we fully agree with each other. Look at the message formats used in the protocols they have attacked successfully so far. Humorously, security folks seem to have ignored this when designing our protocols. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "ISAKMP" flaws?
At 10:14 AM -0500 11/15/05, Perry E. Metzger wrote: Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.html I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? The advisory itself is at <http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en>. Note that the abstract is "Multiple Vulnerability Issues in Implementation of ISAKMP Protocol", with emphasis on "Implementation of". It appears that this is *not* a problem with ISAKMP or IKE, but instead only a problem with some implementations. A summary would be "when some IKEv1 implementations are sent certain malformed messages, they stop, reboot, or possibly do other bad things". Given that they started this research with sending malformed SNMP packets to SNMP-aware systems (with similar results), it is safe to extrapolate the results to implementations of nearly any protocol to varying extents. It is likely that this applies to IKEv2 as well, but using differently-malformed packets. It is also likely that it applies to some SSL/TLS implementations, of course using very different malformed packets. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PKI too confusing to prevent phishing, part 28
At 9:39 PM +0200 9/26/05, Amir Herzberg wrote: Is PKI the cause of this? I think not. This is a usability problem. We try to fix this problem (and similar problems) with TrustBar. Indeed we even had incidents where people on the TrustBar team itself, and some security experts using TrustBar, thought there is a bug - why does TrustBar display `Bad Certificate` warning, when FireFox says the site is protected fine? But then we found out it was simply a self-signed site, or a site signed by a CA not in the list of the browser, or the most hard-for-users: a site with a certificate whose issuer is specified as Verisign (say), but with a wrong public key... this last one is really tricky; even expert users get confused in identifying this, even when using the certificate details dialogs (I checked for FireFox and IE). To me, the first paragraph contradicts the second paragraph. Actually, the third sentence of the first paragraph contradicts the first two sentences of that paragraph. I didn't understand this. Please clarify. If it is an inherent usability problem (users not understanding why there are trust anchors they have never heard of in their browser, users not understanding what a hierarchy is, users not understanding revocation, users not understanding the difference between a hierarchy and self-signed certs, and so on), then PKI is the cause of the problem. Looking at decades of experience with PC software, it seems unlikely that TrustBar or anything like it will be deployed and understood by typical users. It is fine to help increase the security for a small (possibly tiny) audience, but please do not conflate that with making the whole market more noticeably secure. Please justify this assertion. Do you think this is the case simply since users will not install it (being an extension)? Correct, although for more reasons than just because it is an extension. Mostly, they will be suspicious of it unless it comes from the browser maker, and in fact because it comes from someone they have never heard of. Why should they trust their security to anyone other than Microsoft? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PKI too confusing to prevent phishing, part 28
At 8:53 AM +0200 9/26/05, Amir Herzberg wrote: Is PKI the cause of this? I think not. This is a usability problem. We try to fix this problem (and similar problems) with TrustBar. Indeed we even had incidents where people on the TrustBar team itself, and some security experts using TrustBar, thought there is a bug - why does TrustBar display `Bad Certificate` warning, when FireFox says the site is protected fine? But then we found out it was simply a self-signed site, or a site signed by a CA not in the list of the browser, or the most hard-for-users: a site with a certificate whose issuer is specified as Verisign (say), but with a wrong public key... this last one is really tricky; even expert users get confused in identifying this, even when using the certificate details dialogs (I checked for FireFox and IE). To me, the first paragraph contradicts the second paragraph. Actually, the third sentence of the first paragraph contradicts the first two sentences of that paragraph. A technology that cannot be made usable, but is widely used anyway, is the cause of its own problems. There are many problems with PKI, and certainly with its implementation in browsers. But secure usability problems are worse. I think our community should try to be constructive. I definitely try myself, hence TrustBar. Please help me: try it and give me feedback, if you are a good programmer, lend a hand improving it; or find other ideas and implement them. Looking at decades of experience with PC software, it seems unlikely that TrustBar or anything like it will be deployed and understood by typical users. It is fine to help increase the security for a small (possibly tiny) audience, but please do not conflate that with making the whole market more noticeably secure. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
PKI too confusing to prevent phishing, part 28
<http://www.informationweek.com/story/showArticle.jhtml?articleID=171200010> Summary: some phishes are going to SSL-secured sites that offer up their own self-signed cert. Users see the warning and say "I've seen that dialog box before, no problem", and accept the cert. From that point on, the all-important lock is showing so they feel safe. Although the company reporting this, SurfControl, is known for alarmism, this is a completely predictable situation. If users can hold one bit and the bit is "look for the lock", then phishers will do anything to get the lock up there. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ECC patents?
At 12:18 PM +0300 9/14/05, Alexander Klimov wrote: This hints that indeed only some particular curves are patented. It's not just curves. Certicom has patents for some optimizations and methods for validating the strength of some uses of ECC. Grepping -list_curves of the new openssl (0.9.8) which has a list of curves from SECG, WTLS, NIST, and X9.62 gives not that much: secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field Alternatively, this coverage can be interpreted that NSA is not interested in curves which provide less security than 128-bit AES. Any idea, which alternative is true? Both are probably true. Why would anybody be interested in curves that do not support their minimum strength ciphers? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ECC patents?
At 9:32 AM -0700 9/12/05, James A. Donald wrote: It has been a long time, and no one has paid out money on an ECC patent yet. That's pretty bold statement that folks at Certicom might disagree with, even before <http://www1.ietf.org/proceedings_new/04nov/slides/saag-2/sld1.htm>. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]