Re: [Cryptography] PGP Key Signing parties
On Oct 10, 2013, at 2:31 PM, John Gilmore g...@toad.com 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 stein...@gmail.com 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
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: 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
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. insert chide about your criticism of the exact shade of red used on the curtains in the theater --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: 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 b...@links.org 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
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: 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
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: 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 j...@callas.org 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 6:02 PM +0200 5/8/09, R. Hirschfeld wrote: Date: Tue, 5 May 2009 10:17:00 -0700 From: Paul Hoffman paul.hoff...@vpnc.org 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: Has any public CA ever had their certificate revoked?
At 1:02 AM +1200 5/7/09, Peter Gutmann wrote: Paul Hoffman paul.hoff...@vpnc.org 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 4:11 PM +1200 5/5/09, Peter Gutmann wrote: Thierry Moreau thierry.mor...@connotech.com 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: 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: 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: 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: 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
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
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: 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: 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]
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: 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]
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 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: 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: 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]
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: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]
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=ind0705L=nmbrthryT=0P=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: 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.
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 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.
[[ 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.
anti-rant 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. /anti-rant --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 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: 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: 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=1oref=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 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: 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 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: 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: 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]
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]
Re: Another entry in the internet security hall of shame....
At 9:39 AM +0200 9/1/05, Stephan Neuhaus wrote: Are we now at a point where we must admit that PKI isn't going to happen s/happen/happen in a widely useful fashion/ for the Web s/Web/Web and email/ and that we therefore must face the rewriting of an unknown (but presumably large) number of lines of code to accomodate PSKs? Self-signed certificates that are fingerprinted out-of-band are better than PSKs in some situations, worse in others. If that's so, I believe that PSKs will have deployment problems as large as PKI's that will prevent their widespread acceptance. Bingo. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]