Re: [Cryptography] SSH small RSA public exponent
Tim Hudson t...@cryptsoft.com writes: Does anyone recollect the history behind and the implications of the (open) SSH choice of 35 as a hard-wired public exponent? /* OpenSSH versions up to 5.4 (released in 2010) hardcoded e = 35, which is both a suboptimal exponent (it's less efficient that a safer value like 257 or F4) and non-prime. The reason for this was that the original SSH used an e relatively prime to (p-1)(q-1), choosing odd (in both senses of the word) numbers 31. 33 or 35 probably ended up being chosen frequently so it was hardcoded into OpenSSH for cargo-cult reasons, finally being fixed after more than a decade to use F4. In order to use pre-5.4 OpenSSH keys that use this odd value we make a special-case exception for SSH use */ Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Key stretching
Phillip Hallam-Baker hal...@gmail.com writes: Quick question, anyone got a good scheme for key stretching? http://lmgtfy.com/?q=hkdfl=1 Peter :-). ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
Watson Ladd watsonbl...@gmail.com writes: The obvious solution: Do it right the first time. And how do you know that you're doing it right? PGP in 1992 adopted a bleeding-edge cipher (IDEA) and was incredibly lucky that it's stayed secure since then. What new cipher introduced up until 1992 has had that distinction? Doing it right the first time is a bit like the concept of stopping rules in heuristic decision-making, if they were that easy then people wouldn't be reading this list but would be in Las Vegas applying the stopping rule stop playing just before you start losing. This is particularly hard in standards-based work because any decision about security design tends to rapidly degenerate into an argument about whose fashion statement takes priority. To get back to an earlier example that I gave on the list, the trivial and obvious fix to TLS of switching from MAC- then-encrypt to encrypt-then-MAC is still being blocked by the WG chairs after nearly a year, despite the fact that a straw poll on the list indicated general support for it (rough consensus) and implementations supporting it are already deployed (running code). So do it right the first time is a lot easier said than done. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Universal security measures for crypto primitives
Given the recent debate about security levels for different key sizes, the following paper by Lenstra, Kleinjung, and Thome may be of interest: Universal security from bits and mips to pools, lakes and beyond http://eprint.iacr.org/2013/635.pdf From now on I think anyone who wants to argue about resistance to NSA attack should be required to rate their pet scheme in terms of neerslagverdampingsenergiebehoeftezekerheid (although I'm tempted to suggest the alternative tausendliterbierverdampfungssicherheit, it'd be too easy to cheat on that one). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
d...@geer.org writes: The (U.S.) medical records system that started at the Veterans' Administration and has now spread to all but all parts of the U.S. Federal government that handle electronic health records is ASCII encoded, and readable. Called The Blue Button,[1] there is even an HL7-Blue Button file converter.[2] Score one for human readable. Things like HL7 and EDIFACT/X12 (and ASN.1 in DER/BER form) were never meant to be human-readable, they're meant to be easily machine readable and processable. This is why you have viewers to turn them into human-readable form in any format you want. The problem with formats like XML is that it's never been quite sure what it wants to be, so that the result is neither easily human-readable nor easily machine-readable. Trying to get back on track, I think any attempt at TLS 2 is doomed. We've already gone through, what, about a million messages bikeshedding over the encoding format and have barely started on the crypto. Can you imagine any two people on this list agreeing on what crypto mechanism to use? Or whether identity-hiding (at the expense of complexity/security) should trump simplicity/security 9at the expense of exposing identity information)? Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Jerry Leichter leich...@lrw.com writes: My favorite more recent example of the pitfalls is TL1, a language and protocol used to managed high-end telecom equipment. TL1 has a completely rigorous syntax definition, but is supposed to be readable. For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
Phillip Hallam-Baker hal...@gmail.com writes: Quite, who on earth thought DER encoding was necessary or anything other than incredible stupidity? At least some X.500/LDAP folks thought they could do it. Mind you, we're talking about people who believe in X.500/LDAP here... Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
=?iso-8859-1?Q?Kristian_Gj=F8steen?= kristian.gjost...@math.ntnu.no writes: (For what it's worth, I discounted the press reports about a trapdoor in Dual-EC-DRBG because I didn't think anyone would be daft enough to use it. I was wrong.) +1. It's the Vinny Gambini effect (from the film My Cousin Vinny): Judge Haller: Mr. Gambini, didn't I tell you that the next time you appear in my court that you dress appropriately? Vinny: You were serious about dat? And it's not just Dual-EC-DRBG that triggers the You were serious about dat? response, there are a number of bits of security protocols where I've been... distinctly surprised that anyone would actually do what the spec said. (Having said that, I've also occasionally been pleasantly surprised when, by unanimous unspoken consensus among implementers, everyone ignored the spec and did the right thing). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
ianG i...@iang.org writes: Well, defaults being defaults, we can assume most people have left it in default mode. I suppose we could ask for research on this question, but I'm going to guess: most. âSoftware Defaults as De Facto Regulation: The Case of Wireless APsâ, Rajiv Shah and Christian Sandvig, Proceedings of the 33rd Research Conference on Communication, Information and Internet Policy (TPRCâ07), September 2005, reprinted in Information, Communication, and Society, Vol.11, No.1 (February 2008), p.25. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] forward-secrecy =2048-bit in legacy browser/servers? (Re: RSA equivalent key length/strength)
Adam Back a...@cypherspace.org writes: Is there a possibility with RSA-RSA ciphersuite to have a certified RSA signing key, but that key is used to sign an RS key negotiation? Yes, but not in the way you want. This is what the 1990s-vintage RSA export ciphersuites did, but they were designed so you couldn't use them to provide strong security. I imagine that ciphersuite is widely disabled at this point. That'd be the other problem :-). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
Stephen Farrell stephen.farr...@cs.tcd.ie writes: That's a mischaracterisation I think. Some folks (incl. me) have said that 1024 DHE is arguably better that no PFS and if current deployments mean we can't ubiquitously do better, then we should recommend that as an option, while at the same time recognising that 1024 is relatively short. +1. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
Peter Fairbrother zenadsl6...@zen.co.uk writes: On 24/09/13 05:27, Peter Gutmann wrote: Peter Fairbrother zenadsl6...@zen.co.uk writes: If you just want a down-and-dirty 2048-bit FS solution which will work today, why not just have the websites sign a new RSA-2048 sub-certificate every day? Or every few hours? And delete the secret key, of course. ... and I guess that puts you firmly in the theoretical/impractical camp. Would you care to explain how this is going to work within the TLS protocol? I'm not sure I understand you. Something that can sign a new RSA-2048 sub-certificate is called a CA. For a browser, it'll have to be a trusted CA. What I was asking you to explain is how the browsers are going to deal with over half a billion (source: Netcraft web server survey) new CAs in the ecosystem when websites sign a new RSA-2048 sub-certificate. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
Patrick Pelletier c...@funwithsoftware.org writes: I'm inclined to agree with you, but you might be interested/horrified in the 1024 bits is enough for anyone debate currently unfolding on the TLS list: That's rather misrepresenting the situation. It's a debate between two groups, the security practitioners, we'd like a PFS solution as soon as we can, and given currently-deployed infrastructure DH-1024 seems to be the best bet, and the theoreticians, only a theoretically perfect solution is acceptable, even if it takes us forever to get it. (You can guess from that which side I'm on). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
Peter Fairbrother zenadsl6...@zen.co.uk writes: If you just want a down-and-dirty 2048-bit FS solution which will work today, why not just have the websites sign a new RSA-2048 sub-certificate every day? Or every few hours? And delete the secret key, of course. ... and I guess that puts you firmly in the theoretical/impractical camp. Would you care to explain how this is going to work within the TLS protocol? It's easy enough to throw out these hypothetical what-if's (gimme ten minutes and I'll dream up half a dozen more, all of them theoretically OK, none of them feasible), but they need to actually be deployable in the real world, and that's what's constraining the current debate. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Gilmore response to NSA mathematician's make rules for NSA appeal
Walter van Holst walter.van.ho...@xs4all.nl writes: These are not rights that are solely vested in the exceptional Americans. The Bill of Tights [...] For people unfamiliar with this one, it's the bit that reads: Congress shall make no law respecting the wearing of hosiery, or prohibiting the free exercise thereof; or abridging the freedom of colour selection, or of the material used; or the right of the people peaceably to assemble, and to petition the manufacturers for a redress of manufacturing defects. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
Tony Arcieri basc...@gmail.com writes: On Mon, Sep 16, 2013 at 9:44 AM, Bill Frantz fra...@pwpconsult.com wrote: After Rijndael was selected as AES, someone suggested the really paranoid should super encrypt with all 5 finalests in the competition. Five level super encryption is probably overkill, but two or three levels can offer some real advantages. I wish there was a term for this sort of design in encryption systems beyond just defense in depth. AFAICT there is not such a term. How about the Failsafe Principle? ;) How about Stannomillinery? Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
zooko zo...@zooko.com writes: I agree that randomness-reuse is a major issue. Recently about 55 Bitcoin were stolen by exploiting this, for example: http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ Was that the change that was required by FIPS 140, or a different vuln? Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
Dave Horsfall d...@horsfall.org writes: Given that there is One True Source of randomness to wit radioactive emission, has anyone considered playing with old smoke detectors? The ionising types are being phased out in favour of optical (at least in Australia) so there must be heaps of them lying around. If you're in Australia you don't need to use smoke detectors, you've got direct access to the real stuff. I've used a lump of Australian uranium ore with my geiger counter in the past. Problem is that this is hardly scalable. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Ben Laurie b...@links.org writes: We need to get an extension number allocated, since the one it uses clashes with ALPN. It does? draft-ietf-tls-applayerprotoneg-01 doesn't mention ID 0x10 anywhere. (In any case -encrypt-then-MAC got there first, these Johnny-come-lately's can find their own ID to squat on :-). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Market demands for security (was Re: Opening Discussion: Speculation on BULLRUN)
Phillip Hallam-Baker hal...@gmail.com writes: People buy guns despite statistics that show that they are orders of magnitude more likely to be shot with the gun themselves rather than by an attacker. Some years ago NZ abolished its offensive (fighter) air force (the choice was either to buy all-new, meaning refurbished, jets at a huge cost or abolish the capacity). Lots of people got very upset about this, because it was leaving us defenceless. (For people who are wondering why this position is silly, have a look at the position of New Zealand on a world map. The closest country with direct access to us (in other words that wouldn't have to go through other countries on the way here) is Peru, and they don't have any aircraft carriers). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Protecting Private Keys
Jeffrey I. Schiller j...@mit.edu writes: If I was the NSA, I would be scavenging broken hardware from âinterestingâ venues and purchasing computers for sale in interesting locations. I would be particularly interested in stolen computers, as they have likely not been wiped. Just buy second-hand HSMs off eBay, they often haven't been wiped, and the PINs are conveniently taped to the case. I have a collection of interesting keys (or at least keys from interesting places, including government departments) obtained in this way. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Ralph Holz ralph-cryptometz...@ralphholz.de writes: I've followed that list for a while. What I find weird is that there should be much dissent at all. This is about increasing security based on adding quite well-understood mechanisms. What's to be so opposed to there? There wasn't really much dissent (there was some discussion, both on and off- list, which I've tried to address in updates of the draft), it's just that the WG chairs don't seem to want to move on it. Does adding some ciphersuites really require an extension, maybe even on the Standards Track? I shouldn't think so, looking at the RFCs that already do this, e.g. RFC 5289 for AES-GCM. Just go for an Informational. FWIW, even HTTPS is Informational. I've heard from implementers at Large Organisations that having it non- standards-track makes it hard to get it adopted there. I guess I could go for Informational if all else fails. I don't think it hurts to let users and operators vote with their feet here. That's what's already happened/happening, problem is that without an RFC to nail down at least the extension ID it's a bit hard for commercial vendors to commit to it. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
ianG i...@iang.org writes: And, controlling processes is just what the NSA does. https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html How does '(a) Organizations and Conferences' differ from SOP for these sorts of things? Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Ralph Holz ralph-cryptometz...@ralphholz.de writes: But for right now, what options do we have that are actually implemented somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST, etc.), and I don't see any move towards TLS 1.0. http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-02 fixes all of these, I just can't get any traction on it from the TLS WG chairs. Maybe they're following http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html :-). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] tamper-evident crypto? (was: BULLRUN)
John Denker j...@av8n.com writes: To say the same thing the other way, I was always amazed that the Nazis were unable to figure out that their crypto was broken during WWII. There were experiments they could have done, such as sending out a few U-boats under strict radio silence and comparing their longevity to others. Cognitive dissonance. We have been..., sorry Ve haff been reassured zat our cipher is unbreakable, so it must be traitors, bad luck, technical issues, Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Perry E. Metzger pe...@piermont.com writes: I would like to open the floor to *informed speculation* about BULLRUN. Not informed since I don't work for them, but a connect-the-dots: 1. ECDSA/ECDH (and DLP algorithms in general) are incredibly brittle unless you get everything absolutely perfectly right. 2. The NSA has been pushing awfully hard to get everyone to switch to ECDSA/ECDH. Wasn't Suite B promulgated in the 2005-2006 period? Peter (who choses RSA over ECC any time, follow a few basic rules and you're safe with RSA while ECC is vulnerable to all manner of attacks, including many yet to be discovered). ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
Perry E. Metzger pe...@piermont.com writes: I can think of no circumstances where I would voluntarily use LDAP as the solution to any problem of any sort. Our direct competitor has asked us to recommend a technology for whatever it is that LDAP is meant to be the solution for. What should we recommend to them?. (Bit of an artificial example, but between that and Corba you can really mess up someone's business). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
[Apparently a pile of my mail got dropped, the following few messages are re-sends] The Doctor dr...@virtadpt.net writes: It might be a reasonable way of protecting PGP key information in DNS records so that someone doesn't try inserting their own when it's looked up. And that's the problem with DNS, it's the only global distributed database that we've got, so everyone wants to use it as the universal substrate for, well, anything. We'd just need to get draft-ietf-dnsind-kitchen-sink-02.txt adopted and people could cram anything they liked into the DNS. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
John Kelsey crypto@gmail.com writes: If I had to bet, I'd bet on bad rngs as the most likely source of a breakthrough in decrypting lots of encrypted traffic from different sources. If I had to bet, I'd bet on anything but the crypto. Why attack when you can bypass [1]. Peter. [1] From Shamir's Law [2], crypto is bypassed, not penetrated. [2] Well I'm going to call it a law, because it deserves to be. [3] This is a recursive footnote [3]. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
Phillip Hallam-Baker hal...@gmail.com writes: To backup the key we tell the device to print out the escrow data on paper. Let us imagine that there there is a single sheet of paper which is cut into six parts as follows: You read my mind :-). I suggested more or less this to a commercial provider a month or so back when they were trying to solve the same problem. Specifically it was if you lose your key/password/whatever, you can't call the helpdesk to get your data back, it's really gone, which was causing them significant headaches because users just weren't expecting this sort of thing. My suggestion was to generate a web page in printable format with the key shares in standard software-serial-number form (X-X-X etc) and tell people to keep one part at home and one at work, or something similar, and to treat it like they'd treat their passport or insurance documentation. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Perry E. Metzger pe...@piermont.com writes: At the very least, anyone whining at a standards meeting from now on that they don't want to implement a security fix because it isn't important to the user experience or adds minuscule delays to an initial connection or whatever should be viewed with enormous suspicion. I think you're ascribing way too much of the usual standards committee crapification effect to enemy action. For example I've had an RFC draft for a trivial (half a dozen lines of code) fix for a decade of oracle attacks and whatnot on TLS sitting there for ages now and can't get the TLS WG chairs to move on it (it's already present in several implementations because it's so simple, but without a published RFC no-one wants to come out and commit to it). Does that make them NSA plants? There's drafts for one or two more fairly basic fixes to significant problems from other people that get stalled forever, while the draft for adding sound effects to the TLS key exchange gets fast-tracked. It's just what standards committees do. (If anyone knows of a way of breaking the logjam with TLS, let me know). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Jon Callas j...@callas.org writes: My opinion about GCM and GMAC has not changed. I've never been a fan. Same here. AES is, as far as we know, pretty secure, so any problems are going to arise in how AES is used. AES-CBC wrapped in HMAC is about as solid as you can get. AES-GCM is a design or coding accident waiting to happen. This isn't the 1990s, we don't need to worry about whether DES or FEAL or IDEA or Blowfish really are secure or not, we can just take a known-good system off the shelf and use it. What we need to worry about now is deployability. AES- CTR and AES-GCM are RC4 all over again, it's as if we've learned nothing from the last time round. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Jon Callas j...@callas.org writes: How do you feel (heh, I typoed that as feal) about the other AEAD modes? If it's not a stream cipher and doesn't fail catastrophically with IV reuse then it's probably as good as any other mode. Problem is that at the moment modes like AES-CTR are being promulgated as fashion statements without any consideration about operational deployment, when what we should be promoting is something that's safely and effectively deployable. Someblockcipher-CBC + HMAC is a nice safe bet, run your HMAC, do a constant-time compare of the result, toss the encrypted data if you get a verify failure, otherwise decrypt, it's pretty straightforward. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
Ralph Holz ralph-cryptometz...@ralphholz.de writes: There is a host of older literature, too - P2P research, however, has become a cold topic. Although I expect that it will see a revival in the face of surveillance. For people who are interested, the list I have (for a year or two back) is: Security Considerations for Peer-to-Peer Distributed Hash Tables, Emil Sit and Robert Morris, Proceedings of the 1st International Workshop on Peer-to- Peer Systems (IPTPS'01), Springer-Verlag LNCS No.2429, March 2002, p.261. A Survey of Peer-to-Peer Security Issues, Dan Wallach, Proceedings of the 2002 International Symposium on Software Security (ISSS'02), Springer-Verlag LNCS No.2609, November 2002, p.42. Eclipse Attacks on Overlay Networks: Threats and Defenses, Atul Singh, Tsuen-Wan Ngan, Peter Druschel and Dan Wallach, Proceedings of the 25th International Conference on Computer Communications (INFOCOM'06), April 2006, The Index Poisoning Attack in P2P File Sharing Systems, Jian Liang, Naoum Naoumov and Keith Ross, Proceedings of the 25th Conference on Computer Communications (INFOCOM'06), April 2006, Conducting and Optimizing Eclipse Attacks in the Kad Peer-to-Peer Network, Michael Kohnen, Mike Leske and Erwin Rathgeb, Proceedings of the 8th IFIP-TC 6 Networking Conference (Networking'09), Springer-Verlag LNCS No.5550, May 2009, p.104. Combating Index Poisoning in P2P File Sharing, Lingli Deng, Yeping He and Ziyao Xu, Proceedings of the 3rd Conference and Workshops on Advances in Information Security and Assurance (ISA'09), Springer-Verlag LNCS No.5576, June 2009, p.358. Hashing it out in public: Common failure modes of DHT-based anonymity schemes, Andrew Tran, Nicholas Hopper and Yongdae Kim, Proceedings of the 8th Workshop on Privacy in the Electronic Society (WPES'09), November 2009, p.71. Poisoning the Kad Network, Thomas Locher, David Mysicka, Stefan Schmid and Roger Wattenhofer, Proceedings of the 11th International Conference on Distributed Computing and Networking (ICDCN'10), Springer-Verlag LNCS No.5935, January 2010, p.195. If there's anything significant I've missed, feel free to fill in the gaps. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Computer health certificate plan: Charney of DoJ/MS
Before people get too far into conspiracy theories with this, I should point out that health certificates have been part of corporate Windows environments for years (I don't know how many exactly, I think it's been since at least Server 2003). The intent of health certs is that it allows the IT department to manage PCs by allowing checks that they have the latest AV updates installed, the corporate desktop background and Windows theme, the corporate mail client in an up-to-date version, and so on. In other words it's a configuration management solution. Think cfengine with certs. In this case it looks like a MS spokesperson has decided that the existing cfengine-with-certs approach used in corporate environments would work on an ISP-wide or even nation-wide level. It's no conspiracy theory, just a case of either cluelessness about scaling issues or misreporting of a blue-sky, what- if proposal. I'd guess it's the latter. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Formal notice given of rearrangement of deck chairs on RMS PKItanic
Victor Duchovni victor.ducho...@morganstanley.com writes: What are EE certs, did you mean EV? End-entity certs, i.e. non-CA certs. This means that potentially after the end of this year and definitely after 2013 it will not be possible to use any key shorted than 2048 bits with Firefox. Anyone using, for example, an embedded device adminstered via SSL will have to use another browser. From the discussion on the Mozilla policy list I get the impression that this move has been given pretty much zero thought beyond we need to do what NIST wants. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: What if you had a very good entropy source, but only practical at crypto engine installation time?
Thierry Moreau thierry.mor...@connotech.com writes: The PUDEC (Practical Use of Dice for Entropy Collection) scheme has been advanced. The new web page is at http://pudec.connotech.com Plus the PUDEC dice sets are now offered for sale. Hmm, they're somewhat expensive... a cheaper alternative, even if they require a bit more manual effort, are these: http://www.amazon.com/Gamestation-d16-Hexidice/dp/B0012YVYXU (16-sided dice numbered 0...F, $1 each, although shipment outside the US is damn expensive). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Formal notice given of rearrangement of deck chairs on RMS PKItanic
Matt Crawford craw...@fnal.gov writes: EE = End Entity, but I don't read the first sentence the way Peter did. As I mentioned in my previous followup, it's badly worded, but the intent is to ban any keys 2K bits of any kind (currently with evolving weasel-words about letting CAs certify them up to 2013 or so if the user begs really hard). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Formal notice given of rearrangement of deck chairs on RMS PKItanic
From https://wiki.mozilla.org/CA:MD5and1024: December 31, 2010 - CAs should stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits [0]. All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root. Under no circumstances should any party expect continued support for RSA key size smaller than 2048 bits past December 31, 2013. This date could get moved up substantially if necessary to keep our users safe. We recommend all parties involved in secure transactions on the web move away from 1024-bit moduli as soon as possible. Right, because the problem with commercial PKI is all those attackers who are factoring 1024-bit moduli, and apart from that every other bit of it works perfectly. Peter. [0] This is ambiguously worded, but it's talking about key sizes in EE certs. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps
Jerry Leichter leich...@lrw.com writes: By the way, the don't acknowledge whether it was the login ID or the password that was wrong example is one of those things everyone knows - along with change your password frequently - that have long passed their use by date. You got there before I did - real-world studies of users have shown that a common failure mode for this is that when users get their user name wrong they then try every password they can think of under the assumption that they've remembered the wrong password for the site. So not only does not distinguishing between incorrect username and incorrect password not help [0], it actually makes things much, much worse by training users to enter every password for every site they know. Peter. [0] Well, it helps the attackers I guess... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Something you have, something else you have, and, uh, something else you have
From the ukcrypto mailing list: Just had a new Lloyds credit card delivered, it had a sticker saying I have to call a number to activate it. I call, it's an automated system. It asks for the card number, fair enough. It asks for the expiry date, well maybe, It asks for my DOB, the only information that isn't actually on the card, but no big secret. And then it asks for the three-digit-security-code- on-the-back, well wtf? AIUI, and I may be wrong, the purpose of activation is to prevent lost-in- the-post theft/fraud - so what do they need details which a thief who has the card in his hot sweaty hand already knows for? Looks like it's not just US banks whose interpretation of n-factor auth is n times as much 1-factor auth. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
More on padding oracles
Brian Holyfield has created another implementation of the padding oracle exploitation tool first described by Juliano Rizzo and Thai Duong, as well as providing a step-by-step, easy-to-understand explanation of how the attack works, you can find it at: http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/ Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps
Tom Ritter t...@ritter.vg writes: What's weird is I find confusing literature about what *is* the default for protecting the viewstate. I still haven't seen the paper/slides from the talk so it's a bit hard to comment on the specifics, but if you're using .NET's FormsAuthenticationTicket (for cookie-based auth, not viewstate protection) then you get MAC protection built-in, along with other nice features like sliding cookie expiration (the cookie expires relative to the last active use of the site rather than an absolute time after it was set). I've used it in the past as an example of how to do cookie-based auth right Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
A mighty fortress is our PKI, Part III
Some more amusing anecdotes from the world of PKI:
- A standard type of fraud that's been around for awhile is for scammers to
set up an online presence for a legit offline business, which appears to
check out when someone tries to verify it. A more recent variation on this
is to buy certs for legit businesses. One of these certs was traced back by
a security researcher who found that the scammers had obtained it through
the incredibly devious trick of shopping round commercial CAs until they
found one that was prepared to sell them a certificate.
- In a repeat of the original race to the bottom with non-EV certs, CA's have
issued EV certs for RFC 1918 addresses (!!!). What makes this particularly
entertaining is that in combination with a router warkitting attack and
Moxie Marlinspike's OCSP faking it allows an attacker to spoof any EV-cert
site.
- The list of people who have bought certificates for Apple from commercial
CAs keeps on growing (I guess Microsoft is just so five minutes ago :-).
For example one SMTP admin needed a cert for his server and wondered what
would happen if he asked for one for *.apple.com instead of his actual
domain name. $100 and a cursory check later he had a wildcard cert for
Apple. At least two more users have reported buying certificates for Apple,
and there are probably even more lurking out there - if you too have a
certificate from a certificate vending machine saying that you're Apple, do
get in touch
- There's malware out there that pokes fake Verisign certificates into the
Windows trusted cert store, allowing the malware authors to be their own
Verisign.
- CAs have issued certs to cybercrime web sites like
https://www.pay-per-install.com (an affiliate program for malware
installers), because hey, the Russian mafia's money is as good as anyone
else's.
- One of the most important things a CA needs to manage is certificate serial
numbers, because the combination { CA name, cert serial number } is a unique
identifier used in lots of security protocols to identify certs. Without
this uniqueness, you can't tell who signed something, you can't revoke a
cert, you can't... well, you get the idea. Not only have commercial CAs
issued certs with duplicate serial numbers, they've issued *CA certs* with
duplicate serial numbers. Ouch!
(When this was pointed out to the CA who did this - oops, my bad, we'll get
those re-issued for you - someone else pointed out that their OCSP
responder certs had expired, which none of the CA's clients appeared to have
noticed until then. Yeah, we'll look into fixing those too. Anything else
while we're at it?).
If anyone has any further amusing PKI stories, please get in touch, I'd love
to add a Part IV to this series.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Debian encouraging use of 4096 bit RSA keys
Perry E. Metzger pe...@piermont.com writes: One wonders what security model indicated 4096 bits is the ideal length The one that says that if you wind things up past 11 (4096 bits), various things break. (D'you really think they applied any kind of security analysis to the choice of key size? They just wound it up until they got to 11, then declared that the new key size). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel plans crypto-walled-garden for x86
John Gilmore g...@toad.com writes: Let me guess -- to run anything but Windows, you'll soon have to jailbreak even laptops and desktop PC's? Naah, we're perfectly safe, like every other similar attempt after 5-10 years of effort and several hundred million dollars down the drain it'll come to nothing. I guess that's one silver lining of the corollary to We can't secure PCs against the bad guys, which is We can't 'secure' them against their owners either (with the rider ... although we can cause a lot of cost and inconvenience in trying). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fw: [IP] Malware kills 154
Perry E. Metzger pe...@piermont.com forwards: Authorities investigating the 2008 crash of Spanair flight 5022 have discovered a central computer system used to monitor technical problems in the aircraft was infected with malware http://www.msnbc.msn.com/id/38790670/ns/technology_and_science-security/?gt1=43001 Sigh, yet another attempt to use the dog ate my homework of computer problems, if their fly-by-wire was Windows XP then they had bigger things to worry about than malware. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Has there been a change in US banking regulations recently?
Ray Dillinger b...@sonic.net writes: On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote: The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. I'm under the impression that 2048 keys are now insecure mostly due to advances in factoring algorithms Insecure against what? Given the million [0] easier attack vectors against web sites, which typically range from trivial all the way up to relatively easy, why would any rational attacker bother with factoring even a 1024-bit key, with a difficulty level of quite hard? It's not as if these keys have to remain secure for decades, since the 12-month CA billing cycle means that you have to refresh them every year anyway. Given both the state of PKI and the practical nonexistence of attacks on crypto of any strength because it's not worth the bother, would the attackers even notice if you used a 32-bit RSA key? How would an adversary effectively scale and monetise an attack based on being able to break an RSA key, even if it was at close to zero cost? The unfortunate effect of such fashion-statement crypto recommendations as you must use 2K bit keys, regardless of the threat environment is that what it actually says is you must not use SSL on your web site. Le mieux est l'ennemi du bien strikes again. Peter. [0] Figure exaggerated slightly for effect. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Has there been a change in US banking regulations recently?
As part of a thread on another list, I noticed that Bank of America, who until recently didn't bother protecting the page where users are expected to enter their credentials with anything more substantial than a GIF of a padlock, now finally use HTTPS on their home page, and redirect HTTP to HTTPS (this only took them, what, about ten years to get right? Or is it fifteen? When did BofA first get a web presence?). Wachovia now do it too. And Citibank at least redirect you to an HTTPS page. And so does US Bank, after asking for your ID. What on earth happened? Was there a change in banking regulations in the last few months? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Thor Lancelot Simon t...@rek.tjls.com writes: If you want to see a PKI tragedy in the making, have a look at the CRLs used by the US DoD. Only in the making? Actually it's all relative, in Japan the Docomo folks turned off CRLs because they found that even a relatively modest CRL (not just the DoD monsters) presented a nice DoS when sent over cellular data links. What happened was that as the CRLs grew, performance got worse and worse as the phone downloaded the CRL. It took them quite some time to diagnose that they were being DoS'd by their own PKI. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
David-Sarah Hopwood david-sa...@jacaranda.org writes: Huh? I don't understand the argument being made here. It's a bogus argument, the text says: He took a legitimate software package and removed the signature of the digital certificate it contained, then installed the package on his computer. The Installer application didn't indicate that the certificate had been modified. The certificate wasn't modified, they just stripped the signature from the executable. Only an expert will be able to detect a problem, Schouwenberg said. And all Microsoft will tell you is that the file is not signed. And what else should Windows say? We put this through our time machine and noticed that at some time in the past it was signed and now it isn't? The rest of the story isn't much better: The Stuxnet worm, which surfaced last month, used fake Verisign digital certificates No, they were genuine certs, just in the wrong hands. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Jon Callas j...@callas.org writes: But S.J. Perleman's Three Shares in a Boat Uhh. minor nitpick, it was Jerome K.Jerome who wrote Three Shares in a Boat. He followed it up with Three Certificates on the Bummel, a reference to the sharing of commercial vendors' code-signing keys with malware authors. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Preventing a recurrence of the Realtek/JMicron fiasco
I've been having an off-list discussion with someone about how you'd prevent the recent Realtek/JMicron certificate fiasco. My thoughts on this: Since many development shops see the signing process as nothing more than an annoying speed-bump that stands in the way of application deployment, not helped by the fact that code-signing tools like Windows SignTool and Unix' GPG are hard to use and poorly integrated into the development process, developers have generally used the most expedient means possible to sign their code, with signing keys left unprotected or with easy-to-guess passwords (trivial variations of password are a favourite in web advice columns that give examples of how to do code signing [0]), or passwords hard-coded into the scripts that are needed in order to integrate the signing into the build process. Combine this with the existence of entire families of malware such as Adrenalin, Nuklus/Apophis, Ursnif, and Zeus that integrate key-stealing functionality and it's inevitable that legitimate code-signing keys will end up in the hands of malware authors. [0] p...@ssw0rd is the password1 of code signing. So my advice would be to keep the signing key on a dedicated, non-network- connected machine that takes to-be-signed input from a USB drive with autorun turned off (or, better, Didier Stevens' USB-protection driver installed, http://blog.didierstevens.com/programs/ariad/) and sign that. For test purposes during development you can always sign with test keys, and then only sign the final release once it's passed QA. Even if you don't want to go that far, just getting rid of the current worst practice would be a start, where code-signing keys are just random data to be copied onto every developer's machine with no password or a fixed password coded into batch files. Potential issues/discussion topics: - The signing tools should include a test key along the lines of the EICAR test virus sig. that's included by default and recognised everywhere as being purely a test key, to create a zero-overhead way of leaping the signing hurdle during development. - As an extension of the above, the development environment should have some checkbox option to test-sign debug builds of binaries so developers don't have to google + cutpaste obscure command-line strings and batch files into equally obscure config dialogs in their IDE. - Developers may need to repeatedly sign test releases and beta releases. How do you distinguish signature for testing purposes from signature for live release? Pretty much anything you do, e.g. throw up a warning every time a test-signed version is run, is going to cause enough discomfort eventually that developers will go back to using the release key. Any other issues that anyone can think of? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Using file-hiding rootkits for good
I recently came across an example of a file-hiding rootkit for Windows that's used for good instead of evil: It's a minifilter that hides (or at least blocks, the files are still visible) access to executables on removable media, with user-configurable options to block autorun.inf and/or all executables, as well as making files on the media non-executable (although you could still map them into memory and then execute them from there if you really wanted to). This is a neat idea, since it stops a pile of exploits that take advantage of the autorun capability. More at http://blog.didierstevens.com/programs/ariad/. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
Jerry Leichter leich...@lrw.com writes: One could certainly screw up the design of a recovery system, but one would have to try. There really ought not be that much of difference between recovering from m pieces and recovering from one. There's a *huge* difference, see my previous posting on this the last time the topic came up, http://www.mail-archive.com/cryptography@metzdowd.com/msg07671.html: the cognitive load imposed is just so high that most users can't cope with it, particularly since they're already walking on eggshells because they're working on hardware designed to fail closed (i.e. lock everything out) if you as much as look at it funny. The last time I went through this exercise for a high-value key, after quite some time going through the various implications, by unanimous agreement we went with lock an encrypted copy in two different safes (this was for an organisation with a lot of experience with physical security, and their threat assessment was that anyone who could compromise their physical security would do far more interesting things with the capability than stealing a key). For the case of DNSSEC, what would happen if the key was lost? There'd be a bit of turmoil as a new key appeared and maybe some egg-on-face at ICANN, but it's not like commercial PKI with certs with 40-year lifetimes hardcoded into every browser on the planet is it? Presumably there's some mechanism for getting the root (pubic) key distributed to existing implementations, could this be used to roll over the root or is it still a manual config process for each server/resolver? How *is* the bootstrap actually done, presumably you need to go from no certs in resolvers to certs in resolvers through some mechanism. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
Jerry Leichter leich...@lrw.com writes: Here's how I would do it: Key segments are stored on USB sticks. There's a spot on the device with m USB slots, two buttons, and red and green LED's. You put your USB keys into the slots and push the first button. If the red LED lights - you don't have enough sticks, or they aren't valid. If the green LED lights, you have a valid key. If the green LED lights, you push the second button (which is otherwise disabled), and the device loads your key. That's a good start, but it gets a bit more complicated than that in practice because you've got multiple components, and a basic red light/green light system doesn't really provide enough feedback on what's going on. What you'd need in practice is (at least) some sort of counter to indicate how many shares are still outstanding to recreate the secret (We still need two more shares, I guess we'll have to call Bob in from Bratislava after all). Also the UI for recreating shares if one gets lost gets tricky, depending on how much metadata you can assume if a share is lost (e.g. We've lost share 5 of 7 vs. We've lost one of the seven shares), and suddenly you get a bit beyond what the UI of an HSM is capable of dealing with. With a two-share XOR it's much simpler, two red LEDs that turn green when the share is added, and you're done. One share is denoted 'A' and the other is denoted 'B', that should be enough for the shareholder to remember. If you really wanted to be rigorous about this you could apply the same sort of analysis that was used for weak/stronglinks and unique signal generators to see where your possible failure points lie. I'm not sure if anyone's ever done this [0], or whether it's just build in enough redundancy that we should be OK. Peter. [0] OK, I can imagine scenarios where it's quite probably been done, but anyone involved in the work is unlikely to be allowed to talk about it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
Thierry Moreau thierry.mor...@connotech.com writes: With the next key generation for DNS root KSK signature key, ICANN may have an opportunity to improve their procedure. What they do will really depend on what their threat model is. I suspect that in this case their single biggest threat was lack of display of sufficient due diligence, thus all the security calisthenics (remember the 1990s Clipper key escrow procedures, which involved things like having keys generated on a laptop in a vault with the laptop optionally being destroyed afterwards, just another type of security theatre to reassure users). Compare that with the former mechanism for backing up the Thawte root key, which was to keep it on a floppy disk in Mark Shuttleworth's sock drawer because no-one would ever look for it there. Another example of this is the transport of an 1894-S dime (worth just under 2 million dollars) across the US, which was achieved by having someone dress in somewhat grubby clothes and fly across the country in cattle class with the slabbed coin in his pocket, because no-one would imagine that some random passenger on a random flight would be carrying a ~$2M coin. So as this becomes more and more routine I suspect the accompanying calisthenics will become less impressive. (What would you do with the DNSSEC root key if you had it? There are many vastly easier attack vectors to exploit than trying to use it, and even if you did go to the effort of employing it, it'd be obvious what was going on as soon as you used it and your fake signed data started appearing, c.f. the recent Realtek and JMicron key issues. So the only real threat from its loss seems to be acute embarassment for the people involved, thus the due-diligence exercise). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Is this the first ever practically-deployed use of a threshold scheme?
Apparently the DNS root key is protected by what sounds like a five-of-seven threshold scheme, but the description is a bit unclear. Does anyone know more? (Oh, and for people who want to quibble over practically-deployed, I'm not aware of any real usage of threshold schemes for anything, at best you have combine-two-key-components (usually via XOR), but no serious use of real n- of-m that I've heard of. Mind you, one single use doesn't necessarily count as practically deployed either). Peter (who has two more Perry-DoS-ing conversation-starter posts to make, but will leave them for awhile now :-). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Five Theses on Security Protocols
Perry E. Metzger pe...@piermont.com writes: Inspired by recent discussion, these are my theses, which I hereby nail upon the virtual church door: Are we allowed to play peanut gallery for this? 1 If you can do an online check for the validity of a key, there is no need for a long-lived signed certificate, since you could simply ask a database in real time whether the holder of the key is authorized to perform some action. Based on the ongoing discussion I've now had, both on-list and off, about blacklist-based key validity checking [0], I would like to propose an addition: The checking should follow the credit-card authorised/declined model, and not be based on blacklists (a.k.a. the second dumbest idea in computer security, see http://www.ranum.com/security/computer_security/editorials/dumb/). (Oh yes, for a laugh, have a look at the X.509 approach to doing this. It's eighty-seven pages long, and that's not including the large number of other RFCs that it includes by reference: http://tools.ietf.org/html/rfc5055). The signed certificate is completely superfluous. This is, I suspect, the reason for the vehement opposition to any kind of credit-card style validity checking of keys, if you were to introduce it, it would make both certificates and the entities that issue them superfluous. Peter. [0] It's kinda scary that it's taking this much debate to try and convince people that blacklists are not a valid means of dealing with arbitrarily delegatable capabilities. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann paul.tiemann.use...@gmail.com writes: What if... Firefox (or other) could introduce a big new feature (safety controls) and ask you up front: Do you want to be safer on the internet? The problem is that neither the browser vendor nor the users will see it like this. For the user its: Do you want to have lots of sites that you normally use break? For the browser vendor its: Do you want lots of your users to become frustrated when things stop working for them so that they switch to another browser? Is there a good reason Firefox and other browsers shouldn't just get tough about [various sensible security measures] None of the non-IE browsers can afford to do this because people will just switch back to IE, and this has been observed in usability testing of proposed browser security features by HCI researchers, as soon as anything goes wrong the users switch back to IE, which allows pretty much anything through. You can even get IE as a plugin for other browsers (shudder) in order to make things work. So you'd need to get the change made in IE (or at least get it made in such a manner that fallback-to-IE is no longer an option). I don't know what size hammer you'd need to wield in order to get that done. This isn't true for all OCSP services. For example, DigiCert's is not CRL based, so it really can say Yes It can't say yes because the only thing OCSP can say is not revoked (and in more general terms the only thing a blacklist can say is not on the blacklist). Not revoked doesn't mean valid, it just means not in the blacklist. and it really can say Unknown meaningfully. Unknown is generally treated by client apps as good, because if revoked maps to bad then anything else must map to good (OCSP's muddle of non- orthogonal response types is yet another perpetual motion-machine debate topic among PKI people). It might not be hard to determine whose OCSP responders are CRL based and whose are database backed instead. How can you do this? Note that the various timestamps in OCSP responses are as big a mess as the rest of OCSP, and can't be relied upon for any decision- making. More importantly, how can you possibly make any meaningful decisions in time- critical protocols based on a system for which your responses can have come from any time in the past? As one security architect commented some years ago, learning in 80ms that the certificate was good as of a week ago and to not hope for fresher information for another week seems of limited, if any, utility to us or our customers. The problem here is best seen by looking at certificates as capabilities. 1. You have an abitrary and unknown number of capabilities floating around out there. 2. Some of those capabilities (CA certs) have the ability to mint new capabilities. 2a. These capabilities can impersonate existing capabilities, and because of (1) the real issuer of the capabilities has no idea that they exist. And the means of dealing with these unknown numbers of arbitraily-identified capabilities is... a blacklist. There's no way this can possibly, ever work. It's the 1960s credit-card model that Perry mentioned with the added twist that there are an unknown number of cards and issuers involved, and some of the cards can invent new cards whenever they feel like it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Steven Bellovin s...@cs.columbia.edu writes: When I look at this, though, little of the problem is inherent to PKI. Rather, there are faulty communications paths. Oh no my Lord, I assure you that parts of it are excellent! :-). [...] how should the CA or Realtek know about the problem? [...] That was the whole point, that the whole system doesn't work, and it's the system as a whole that has to work, not just some parts of it. Here's another description, without the possibly confusing 't +/- x' stuff: Shortly after the malware appeared (or at least got noticed) it was added to anti-virus vendor databases and pushed out to users via updates. Some time later when it made headlines because of its use of the Realtek certificate, the CA that had issued it read about it in the news, contacted the certificate owner, and revoked it. However due to the dysfunctional nature of revocation handling, the certificate was still regarded as valid by Windows systems after it had been revoked, and of a range of machines running Windows 7, Vista, and XP, all with the latest updates and hotfixes applied and with automatic updates turned on, the first machine to notice the revocation and treat the signature as invalid didn't do so until a full week after the revocation had occurred, and some machines still regard the signature as valid even now (I've heard this before a number of times in software developer forums and mailing lists, plaintive complaints from users to the effect that I know this certificate is revoked, but no matter what I do I can't get the software to stop using it!). So while PKI and code-signing promise the user a fairly deterministic series of events in which A occurs, the B occurs, then C occurs, and then the user is safe, what actually happens in practice is that A occurs, then a comedy of errors ensues [0], and then the user is still unsafe while possibly being under the mistaken impression that they're actually safe. [0] I've never understood why this is a comedy of errors, it seems more like a tragedy of errors to me. A real-world demonstration of the relative effectiveness of various protection mechanisms occurred when I wanted to evaluate the ability of code-signing to protect users. A researcher sent me a copy of the signed malware (thanks!), and because of its nature encrypted it with AES using the RAR archiver. Because RAR (and indeed most other archivers) don't protect file metadata, the message was blocked by email scanners that identified the overall contents from the metadata even though the file contents themselves were encrypted. After some discussion with the IT people (yes, I am certain what the file is, it's a rather nasty piece of Windows malware, and I trust the sender to have sent me malware) they forwarded the email to the PowerPC Linux machine on which I read email, and which is rather unlikely to be affected by x86 Windows malware. Unfortunately I never could check it on the Windows system that I wanted to test it on because the instant it appeared on there the resident malware protection activated and deleted it again, despite various attempts to bypass the protection. Eventually I got it onto a specially-configured Windows system, which reported that both the signature and its accompanying certificate were valid (this is now two weeks after the CA had declared the certificate revoked). So it actually proved quite difficult to see just how ineffective PKI and code-signing actually was in protecting users from malware because the real protection mechanisms were so effective at doing their job. (It's also rather an eye-opener about the effectiveness, at least in some cases, of malware-protection software, no matter what I did I couldn't get the malware files onto a Windows PC in order to have the code-signing declare them valid and, by implication, perfectly safe). What's interesting here is the claim that AV companies could respond much faster. I'd say it's more than just a claim, the malware was first detected around 1 1/2 months ago and added to AV vendor databases, a full month later the certificate was declared revoked by the CA, and currently the majority of Windows systems still regard the signature as valid (I've had a report from someone else of one machine that records it as revoked, so at least one machine has been belatedly protected by the code signing, assuming the user doesn't just click past the warning as pretty much all of them will). So yes, I'd say the AV companies respond a helluva lot faster, and a helluva lot more effectively. The bigger lesson, for people who ever believed this to be the case, is don't rely on code signing to protect you from malware. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Ben Laurie b...@links.org writes: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. This wouldn't make any difference, except for the special case of x64, signatures are only verified on install, so existing installed code isn't affected and anything new that's being installed is, with either form of sig-checking. In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). The way to revoke a cert for signed malware is to wait 0-12 hours for the malware signature to be added to AV databases, not to actually expect PKI to work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? It's not just that the world doesn't work that way now, it's quite likely that it'll never work that way (for the case of PKI/revocations mentioned in the message, not the original SNI). We've been waiting for between 20 and 30 years (depending on what you define as the start date) for PKI to start working, and your reponse seems to indicate that we should wait even harder. If I look at the mechanisms we've got now, I can identify that commercial PKI isn't helping, and revocations aren't helping, and work around that. I'm after effective practical solutions, not just a solution exists, QED solutions. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Steven Bellovin s...@cs.columbia.edu writes: For the last issue, I'd note that using pki instead of PKI (i.e., many different per-realm roots, authorization certificates rather than identity certificates, etc.) doesn't help: Realtek et al. still have no better way or better incentive to revoke their own widely-used keys. I think the problems go a bit further than just Realtek's motivation, if you look at the way it's supposed to work in all the PKI textbooks it's: Time t: Malware appears signed with a stolen key. Shortly after t: Realtek requests that the issuing CA revoke the cert. Shortly after t': CA revokes the cert. Shortly after t'': Signature is no longer regarded as valid. What actually happened was: Time t: Malware appears signed with a stolen key. Shortly after t: Widespread (well, relatively) news coverage of the issue. Time t + 2-3 days: The issuing CA reads about the cert problem in the news. Time t + 4-5 days: The certificate is revoked by the CA. Time t + 2 weeks and counting: The certificate is regarded as still valid by the sig-checking software. That's pretty much what you'd expect if you're familiar with the realities of PKI, but definitely not PKI's finest hour. In addition you have: Time t - lots: Stuxnet malware appears (i.e. is noticed by people other than the victims) Shortly after t - lots: AV vendors add it to their AV databases and push out updates (I don't know what lots is here, it seems to be anything from weeks to months depending on which news reports you go with). So if I'm looking for a defence against signed malware, it's not going to be PKI. That was the point of my previous exchange with Ben, assume that PKI doesn't work and you won't be disappointed, and more importantly, you now have the freedom to design around it to try and find mechanisms that do work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann paul.tiemann.use...@gmail.com writes: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) That's the key-continuity model, which has been proposed a number of times for Firefox, for example here's a discussion by a FF developer from over two years ago on this, http://blog.johnath.com/2008/04/16/security-ui-in-firefox-3plus1/ (that's specific to FF, I don't know what the IE, Opera, Safari, ... guys talk about). There's no sign of it gaining any traction. I hate to be the perpetual wet blanket here but the problem isn't a lack of ideas (many backed by extensive real-world research) but a lack of motivation in browsers to change the security mechanisms and UI, most of which have remained essentially unchanged (except for cosmetic rearrangement of the chrome every release or so) since the debut of SSL in 1995. That's the mastodon in the room, we can debate ideas pretty much forever but if no browser vendor is interested in adopting any of them it isn't going to help secure users. (Having said that, it's fun to throw around ideas, so I'm not complaining about that bit). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. Specifically, if I submit a freshly-issued, valid certificate to an OCSP responder and ask is this a valid certificate then it can't say yes, and if I submit an Excel spreadsheet to an OCSP responder and ask is this a valid certificate then it can't say no. It takes quite some effort to design an online certificate status protocol that's that broken. (For people not familiar with OCSP, it can't say yes because a CRL can't say yes either, all it can say is not on the CRL, and it can't say no for the same reason, all it can say is not on the CRL. The ability to say vslid certificate or not valid certificate was explicitly excluded from OCSP because that's not how things are supposed to be done). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Nicolas Williams nicolas.willi...@oracle.com writes: Sorry, but this is wrong. The OCSP protocol itself really is an online certificate status protocol. It's not an online certificate status protocol because it can provide neither a yes or a no response to a query about the validity of a certificate. (For an online status protocol I want to be able to submit a cert and get back a straight valid/not valid response, exactly as I can for credit cards with their authorised/declined response. Banks were doing this twenty years ago with creaky mainframes over X.25 and (quite probably) wet bits of string, but we still can't do this today with multicore CPUs and gigabit links if we're using OCSP). Responder implementations may well be based on checking CRLs, but they aren't required to be. They may be, or they may not be, but you as a relying party have no way of telling. OCSP covers not only the three incompatible business models of the different authors' employers but, for good measure, an extra anything else you may care to do option if the first three aren't enough. A decade after it was published, PKI experts are still arguing over what various bits of the OCSP spec actually mean (the PKIX list has only just gone through yet another round of this... *ten years* later and domain experts still can't agree on how it's supposed to work). So given the schizophrenic nature of the RFC you can easily claim but you can do X because chances are if you read it just right you probably can. Unfortunately this doesn't give a relying party much to rely on, because they have absolutely no idea what they're getting, it could be anything from a live database query to a value from a month-old CRL to (thanks to the removal of nonces from the protocol a few years ago) an attacker replaying an old not-revoked value (although I don't know why they'd even bother with that, given the state of revocation checking in client software). In any event though since OCSP can't say yes or no, it doesn't matter whether the response is coming from a live database or a month-old CRL, since it's still a fully CRL-bug-compatible blacklist I can trivially avoid it with a manufactured-cert attack. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann paul.tiemann.use...@gmail.com writes: [...] This is kind of a long message to reply to so I'll just post a meta-reply to avoid getting bogged down in nitpicking, the message, as the subject line indicated, was intended to start a discussion on some of the weaknesses inherent in the SSL and commercial PKI model. I consciously worded it to avoid mentioning any CA names, and only mentioned Edgecast because it was impossible not to (I had to provide a URL for the cert), and even then included a disclaimer that it wasn't a criticism of Edgecast. I actually agree with a lot of the points made in the response, since this wasn't a failing of Edgecast or a CA but a problem in the way SSL's PKI (or more generally just PKI as a whole) works. Because it was designed for the purposes of authenticating a single user to the global X.500 directory it really doesn't have any provision for Sybil certs (I'm going to keep calling them that because we need some sort of label for them :-). The intent with posting it to the list was to get input from a collection of crypto-savvy people on what could be done. The issue had previously been discussed on a (very small) private list, and one of the members suggested I post it to the cryptography list to get more input from people. The follow-up message (the Part II one) is in a similar vein, a summary of a problem and then some starters for a discussion on what the issues might be. So a general response to the several well, what would you do? questions is I'm not sure, that's why I posted this to the list. For example should an SSL cert be held to higher standards than the server it's hosted on? In other words if it's easier to compromise a CDN host or (far more likely) a web app on it, does it matter if you're using a Sybil cert? I have no idea, and I'm open to arguments for and against. I've spoken with my contacts at Edgecast, and they expressed that they're very willing to consider alternate approaches. I'm not actually sure what the fix would be for this, or even if there is a fix that needs to be made. Thus the hope to get it discussed on the list. (Oh, and a comment on the XS* bit, that was based on an earlier off-list discussion on messing with Firefox' same-origin policy protection mechanism and isn't relevant here, the real issue is the more obvious one of a single cert acting for large numbers of totally unrelated domains with very different security requirements). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Ian G i...@iang.org writes: ** But talking about TLS/SNI to SSL suppliers is like talking about the lifeboats on the Titanic ... we don't need it because SSL is unsinkable. ... or talking to PKI standards groups about adding a CRL reason code for certificate issued in error (e.g. to an imposter). This was turned down because CA's never make mistakes, so there's no need to have such a reason code. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
A mighty fortress is our PKI, Part II
Have you ever wondered what would happen if malware started appearing that was authenticated by signing keys belonging to major hardware or software vendors? Over the last week or two we've had a chance to find out: One of the scariest scenarios for code signing is when the malware authors manage to get their hands on a legitimate developer's code-signing key. Since many development shops see the signing process as nothing more than an annoying speedbump that stands in the way of application deployment, not helped by the fact that code-signing tools like Windows SignTool and Unix' GPG are hard to use and poorly integrated into the development process, developers have generally used the most expedient means possible to sign their code, with signing keys left unprotected or with easy-to-guess passwords (password is a favourite in web advice columns that give examples of how to do code signing), or passwords hard-coded into the scripts that are needed in order to integrate the signing into the build process. Combine this with the existence of entire families of malware such as Adrenalin, Nuklus/Apophis, Ursnif, and Zeus, with key-stealing functionality and it's inevitable that legitimate code-signing keys will end up in the hands of malware authors. The most serious case of this occurred in mid-2010 when malware signed with a key belonging to the major semiconductor manufacturer Realtek started to appear [Rootkit.TmpHider, discussion thread, 12 July 2010, http://www.wilderssecurity.com/showthread.php?p=1712134.][Signed Malware Used Valid Realtek Certificate, Lucian Constantin, 16 July 2010, http://news.softpedia.com/news/Signed-Malware-Used-Valid-Realtek- Certificate-147942.shtml.]. Although PKI dogma states that a certificate belonging to such a key should be immediately revoked, the fact that vast numbers of Realtek drivers had already been signed by it and could now no longer be installed without unsigned-driver warnings or, in the case of 64-bit Windows, used at all, would no doubt have given both Realtek and the issuing CA cause for concern. After several days the certificate was revoked [VeriSign working to mitigate Stuxnet digital signature theft, Steve Ragan, 21 July 2010, http://www.thetechherald.com/article.php/201029/5921/VeriSign-working-to- mitigate-Stuxnet-digital-signature-theft.], although the CA had to wait until the story started to appear in news reports before they became aware of the need for the revocation. The decision to revoke the certificate was probably influenced by a combination of the fact that the majority of users will simply click through a driver install warning and that the hit-and-miss nature of revocation checking meant that many systems would keep on using the certificate regardless (if the certificate had only been used to sign 32-bit code so that the worst that could happen was a warning dialog on install for users to click past then this would have made the decision to revoke even easier). In any case since antivirus vendors had added the malware signature to their scanners as soon as it was discovered, the revocation likely had little actual effect in protecting users from harm. A few days later a new version of the malware appeared, this time signed with a key from another semiconductor manufacturer, JMicron [Win32/Stuxnet Signed Binaries, Pierre-Marc Bureau, 19 July 2010, http://blog.eset.com/2010/07/19/win32stuxnet-signed-binaries.][Another Signed Stuxnet Binary, Sean Sullivan, 20 July 2010, http://www.f-secure.com/weblog/archives/1993.html.][New Stuxnet-Related Malware Signed Using Certificate from JMicron, Lucian Constantin, 20 July 2010, http://news.softpedia.com/news/New-Stuxnet-Related-Malware-Signed-Using- Certificate-from-JMicron-148213.shtml.]. Making the debacle even more entertaining was the fact that one of the principal systems targeted by the malware is a Siemens SCADA (industrial control) system that uses a hardcoded password 2WSXcder that can't be changed because doing so causes the system to stop working [Siemens warns users: Don't change passwords after worm attack, Robert McMillan, 20 July 2010, http://www.infoworld.com/d/security-central/siemens-warns-users-dont-change- passwords-after-worm-attack-915.] and that had been circulating on the Internet for years, including being posted to a Siemens online forum in Russia [SCADA System.s Hard-Coded Password Circulated Online for Years, Kim Zetter, 19 July 2010, http://www.wired.com/threatlevel/2010/07/siemens-scada/.] and online lists of default passwords [default password list, http://www.defaultpassword.com/?action=dplchar=s.] (the reason for this poor level of security is that SCADA systems rate availability above everything else, so that anything that affects, or potentially affects, security is strongly avoided. In addition SCADA systems often use thoroughly out-of-date hardware and software that no-one wants to change for fear of breaking things and for which there's no way to
Re: A mighty fortress is our PKI
From an off-list discussion: Can someone who knows more about how these CDNs handle certs provide a brief summary for the list? From looking at Sybil certs grabbed from a few CDN sites there doesn't seem to be any rhyme or reason to them. Also, how and under what conditions can you get access to the CDN as an insider? I'd found ads like http://www.webhostingtalk.com/showthread.php?t=873555, Resell the Edgecast CDN and make a killing!, which seem to imply that anyone with a chequebook can play. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Looks like the CDN certificate is already causing security problems, although not the kind that I was expecting: While trying to import a server certificate for a CDN service, a segv bug was found in [PKI app]. It is likely that this bug is exploitable by sending a special crafted signed message and having a user verify the signature. Hmm, I wonder if this particular certificate happened to be one with 107 subjectAltName entries? Description Importing a certificate with more than 98 Subject Alternate Names via import command or implicitly while verifying a signature causes [...]. Yup :-). So if nothing else it's a good stress test for your certificate- parsing code... Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
A mighty fortress is our PKI
Readers are cordially invited to go to https://edgecastcdn.net and have a look
at the subjectAltName extension in the certificate that it presents. An
extract is shown at the end of this message, this is just one example of many
like it. I'm not picking on Edgecast specifically, I just used this one
because it's the most Sybilly certificate I've ever seen. You'll find that
this one Sybil certificate, among its hundred-and-seven hostnames, includes
everything from Mozilla, Experian, the French postal service, TRUSTe, and the
Information Systems Audit and Control Association (ISACA), through to
Chainlove, Bonktown, and Dickies Girl (which aren't nearly as titillating as
they sound, and QuiteSFW). Still, who needs to compromise a CA when you have
these things floating around on multihomed hosts and CDNs.
Ian Grigg pointed out that this is also an EV certificate, I'm guessing that
CDNs and multihomed hosts run into the same system-high problem that dogged
MLS systems in the 1980s, they have to use the certificate at the highest
level of any of the constituent domains. So if you compromise (say)
inpath-static.iseatz.com (which consists of a page that says We're sorry, but
something went wrong) or images.vrbo.com (Directory Listing Denied) then
you have an EV-validated site. So the overall EV security becomes that of the
least secure co-hosted domain.
I've tried connecting to the above site with HTTPS and get a normal non-EV
Sybil certificate even though it's rooted in an EV CA... well, pseudo-rooted,
the root is then signed by an old Entrust certificate, and the certificate
itself is another multi-domain one, for Delta, Amtrak, Air France, KLM, Alaska
Air, and others. I wonder if they have some context-specific way to override
EV on a per-site basis when it's used with Sybil certificates? At the moment
it's rather hard to test because depending on where you are in the world you
get different views of servers and certificates (for example when I connect to
ISACA, which is an EV site, I get a standard non-Sybil certificate that's only
valid for ISACA), and finding a particular hostname in a Sybil certificate
doesn't mean that you'll see that particular certificate when you connect to
the server.
(Again, not wanting to pick on ISACA here, but finding a security audit
organisation sharing a certificate with Dickies Girl is kinda funny. You'd
think there'd be a security audit process to catch this :-).
What a mess! A single XSS/XSRF/XS* attack, or just a plain config problem,
and the whole house of cards comes down.
(For the TLS folks, SNI (a client-supplied Server Name Indication when it
connects) won't fix this because (a) it's not widely-enough supported yet and
(b) the server admin would have to buy 107 separate certificates to do the
job that's currently done by one Sybil certificate, and then repeat this for
every other Sybil certificate they use).
666 2633: SEQUENCE {
6703: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
675 2624: OCTET STRING, encapsulates {
679 2620: SEQUENCE {
683 15: [2] 'edgecastcdn.net'
700 18: [2] 'ne.edgecastcdn.net'
720 21: [2] 'minitab.fileburst.com'
743 30: [2] 'cdn.montimbrenligne.laposte.fr'
775 27: [2] 'zeroknowledge.fileburst.com'
804 23: [2] 'images.goldstarbeta.com'
829 25: [2] 'radialpoint.fileburst.com'
856 19: [2] 'wac.edgecastcdn.net'
877 22: [2] 'ne.wac.edgecastcdn.net'
901 19: [2] 'images.goldstar.com'
922 15: [2] 'images.vrbo.com'
939 12: [2] 'cdn.vrbo.com'
953 18: [2] 'content.truste.com'
973 13: [2] 'e1.boxcdn.net'
988 13: [2] 'e2.boxcdn.net'
1003 13: [2] 'e3.boxcdn.net'
1018 25: [2] 'privacy-policy.truste.com'
1045 13: [2] 'www.sonos.com'
1060 19: [2] 'www.dickiesgirl.com'
1081 26: [2] 'static-cache.tp-global.net'
1109 29: [2] 'images.homeawayrealestate.com'
1140 14: [2] 'cdn.verint.com'
1156 13: [2] 'swf.mixpo.com'
1171 21: [2] 'cdn.traceregister.com'
1194 14: [2] 's.tmocache.com'
1210 17: [2] 's.my.tmocache.com'
1229 23: [2] 'ne1.wpc.edgecastcdn.net'
1254 23: [2] 'gp1.wpc.edgecastcdn.net'
1279 23: [2] 'gs1.wpc.edgecastcdn.net'
1304 23: [2] 'ne1.wac.edgecastcdn.net'
1329 23: [2] 'gp1.wac.edgecastcdn.net'
1354 23: [2] 'gs1.wac.edgecastcdn.net'
1379 24: [2] 'c1.socialcastcontent.com'
1405 21: [2] 'www.steepandcheap.com'
1428 22: [2] 'www.whiskeymilitia.com'
1452 17: [2] 'www.chainlove.com'
Re: Intel to also add RNG
Paul Wouters p...@xelerance.com writes: Which is what you should do anyway, in case of a hardware failure. I know the Linux intel-rng and amd-rng used to produce nice series of zeros. Do you have any more details on this? Was it a hardware problem, software problem, ...? How was it caught? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fwd: Anyone make any sense out of this skype hack announcement?
Christian Collberg collb...@gmail.com writes: I don't know if the new crack reveals anything new. We have a writeup about the Skype protection techniques in Surreptitious Software, our book on security-through-obscurity. (Sorry for the blatant self-promotion). No need to apologise, it's a damn good read. For people not familiar with it, the title is a bit misleading (it sounds like a book about malware), it's actually a book on software obfuscation and tamperproofing, IMHO it's the definitive reference on the topic. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
Ben Laurie b...@google.com writes: On 2 July 2010 13:19, Eugen Leitl eu...@leitl.org wrote: http://www.technologyreview.com/printer_friendly_article.aspx?id=25670channel=Briefingssection=Microprocessors Tuesday, June 29, 2010 Nanoscale Random Number Circuit to Secure Future Chips Intel unveils a circuit that can pump out truly random numbers at high speed. Have they forgotten the enormous amount of suspicion last time they tried this? You mean rampant paranoia from a small group of people... if you are genuinely worried about this, just use it as another input to mix into your entropy pool (which you should be doing anyway, never trust a single source of entropy). I'd be quite happy to use the RNG on a Loongson CPU (if there was one) in this manner, let alone an Intel CPU. What killed it wasn't paranoia about Intel but their almost total lack of interest in supporting it once the initial media attention waned. This doesn't look any different, note that it's not saying This will be in Core2's starting August but We've done this in the lab. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
Ralph Holz ralph-cryptometz...@ralphholz.de writes: CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. Unfortunately CTR mode, being a stream cipher, fails completely if the IV's/keys aren't fresh (as you could force them to be for SRTP under SIP by attacking the crypto handshake that preceded it, a nice example of attacking across a protocol boundary, taking advantage of a weakness in one protocol to break a second), while CBC only becomes a bit less secure. In addition CTR mode fails trivially to integrity attacks, while with CBC it's often more obvious (you get at least some total corruption before the self-healing takes effect). The problem with CTR is that, like RC4, it's very brittle, make a tiny mistake anywhere and you're toast. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
Ralph Holz ralph-cryptometz...@ralphholz.de writes: CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. Unfortunately CTR mode, being a stream cipher, fails completely if the IV's/keys aren't fresh (as you could force them to be for SRTP under SIP by attacking the crypto handshake that preceded it, a nice example of attacking across a protocol boundary, taking advantage of a weakness in one protocol to break a second), while CBC only becomes a bit less secure. In addition CTR mode fails trivially to integrity attacks, while with CBC it's often more obvious (you get at least some total corruption before the self-healing takes effect). The problem with CTR is that, like RC4, it's very brittle, make a tiny mistake anywhere and you're toast. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Spy/Counterspy
GPS tracking units that you can fit to your car to track where your kids are taking it (or *cough* other purposes) have been around for awhile now. It's interesting to see that recently the sorts of places that'll sell you card skimmers and RFID cloners have started selling miniature GPS jammers that plug into cigarette-lighter sockets on cars (general-purposes ones using internal batteries have been around for awhile). In other words these are specifically designed to stop cars from being tracked. (Some of the more sophisticated trackers will fall back to 3G GSM-based tracking via UMTS modems if they lose the GPS signal, it'll be interested to see how long it takes before the jammers are updated to deal with 3G signals as well, hopefully while leaving 2G intact for phonecalls). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Against Rekeying
Nicolas Williams nicolas.willi...@sun.com writes: I made much the same point, but just so we're clear, SSHv2 re-keying has been interoperating widely since 2005. (I was at Connectathon, and while the details of Cthon testing are proprietary, I can generalize and tell you that interop in this area was very good.) Whose SSH rekeying though? I follow the support forums for a range of non- mainstream (i.e. not the usual suspects of OpenSSH, ssh.com, or Putty) SSH implementations and why does my connection die after an hour with [decryption error/invalid packet/unrecognised message type/whatever] (all signs of rekeying issues) is still pretty much an FAQ across them at the current time. (There's also the mass of ancient copies of the usual suspects, principally the ssh.com implementation dating back up to ten years, baked into networking devices and whatnot that will never be updated, or at least if significant security holes present in the older versions haven't convinced the vendors using them to update them then I don't think the fact that they drop the connection after an hour will). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Phone company phishes its own users
There have been numerous posts to this list about banks phishing their own users so I figured I'd start a new thread about other companies who are potential phishing-targets doing this as well, in this case a phone company. From the fraud-alert support forum of Vodafone: http://forum.vodafone.co.nz/topic/3631-phone-call-from-vodafone-for-check-on-plan-and-confirming-contact-details-including-vf-pin-number/ User: Not sure if this is genuine or not - just had a call from a blocked number caller saying they were from Vodafone doing a 'courtesy' call checking I'm happy on my plan and updating contact details. First thing they ask for is my Date of Birth and Vodafone pin number. Is this genuine? Vodafone staff: I would not be giving out my date of Birth User: So thats a no to it being official then? Vofafone staff: Call was all good nothing to worry about So next time you get a call from a caller-ID-blocked number asking for your PIN, it's OK, it's only your phone company. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Why the onus should be on banks to improve online banking security
There's been a near-neverending debate about who should be responsible for improving online banking security measures: the users, the banks, the government, the OS vendor, ... . Here's an interesting perspective from Peter Benson peter.ben...@codescan.com, reposted with permission, on why the onus should be on banks to provide appropriate security measures: One of the main reasons to target the banks with accountability is because you can. There is a lot of historical regulation and controls around banking, which makes it *relatively* easy to hold them to account. The bigger problem, and the next logical step, is how the banks hold suppliers / vendors of software accountable for flaws in their systems and software that enable the problems to occur in the first place. Anyone recognise the following? This software is provided as is, and any expressed or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability , or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage. Accountability is great, and I fully support it, and would like to somehow find the way to push a level of accountability back to various software developers / manufacturers. Unfortunately in the current state of Contract and Tort law, there is so much protection(ism) of the software industry, that its still going to be time consuming and expensive to get a couple of decent case studies out there or to change anything. So from a public good perspective, unfortunately (realistically), it is the banks that should carry the onus. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
John Levine jo...@iecc.com writes: I told him about an approach to use a security dongle that puts the display and confirmation outside the range of the malware, and although I thought it was fairly obvious, he'd apparently never heard it before. Some general thoughts on this, there have been attempts going back at least ten years to bring devices like this to market (for example I have a nice device that does exactly this built in the late 90s sitting in a drawer somewhere), but they always die for the same reason, lack of interest and, for the few who are interested, lack of interest in paying the cost. I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html [...] I don't understand why banks aren't using this approach already. Because (apart from the reasons given above) with business use specifically you run into insurmountable PC - device communications problems. Many companies who handle large financial transactions are also ones who, due to concern over legal liability, block all access to USB ports to prevent external data from finding its way onto their corporate networks (they are really, *really* concerned about this). If you wanted this to work, you'd need to build a device with a small CMOS video sensor to read data from the browser via QR codes and return little more than a 4-6 digit code that the user can type in (a MAC of the transaction details or something). It's feasible, but not quite what you were thinking of. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Interesting way of protecting credit card data on untrusted hosts
A Canadian company called SmartSwipe has come up with an interesting way to protect credit card numbers from most man-in-the-browser attacks. What they do is install a Windows CSP (cryptographic service provider) that acts as a proxy to an external mag-stripe reader with built-in crypto processing, so the CSP on the host PC does nothing more than forward data to be encrypted out to the external device. There's also a browser plug-in that pre-populates the credit-card field in web forms with a cookie. When the page is sent to the CSP for encryption for SSL, the software running on the reader recognises the cookie in the web-form content, reads the card data via the mag-stripe reader, inserts it into the web-form field, and returns the encrypted result to the host PC to forward to the remote server. As a result, the CC data is never present on the host PC. The downsides are obvious: not secure against phishing (which is a killer), only works with MSIE because of the requirement for use of a CSP (although you could do it with Firefox as well by creating a PKCS #11 soft-token), and not secure against page-rewrite trojans which have the web page show one thing and do another, but it's an interesting concept. You can find a description of the technology under the name Dynamic SSL(tm)(c)(p), a start point is: http://www.smartswipe.ca/en/dynamic-ssl/600-dynamic-ssl-a-practical-solution-for-endpoint-to-endpoint-encryption Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [tahoe-dev] Bringing Tahoe ideas to HTTP
Brian Warner war...@lothar.com writes: From what I can tell, the Sparkle update framework (for OS-X)[1] is doing something like what I want for firefox: the Sparkle-enabled application will only accept update bundles which are signed by a DSA privkey that matches a pubkey embedded in the app. You can extend this further to make it tolerant of key loss by embedding multiple public keys and allowing a quorum of them to replace an existing key. So say you have five keys, you can decide that any three of them can vote out an existing key, allowing compromised keys to be replaced and existing keys to be rolled over. This creates a kind of fault-tolerant PKI which does away with the need to have a CA vouch for key replacements, once you've got the initial keys established (for example on first install) you can recover from anything short of a total compromise, upgrade to larger keys sizes and hashes, and so on. It'd be nice if Firefox could do the same. And if Firefox were to establish a quietly-backwards-compatible convention (i.e. the hash-mark trick) for strong URL-based authentication of HTTP resources, then other applications could start using it too, and a significant class of current web security problems (like the mixed-content one where an HTTPS page loads a javascript library via HTTP) could be fixed. See my previous post, there was an attempt made to do this in the past but it never got anywhere. It'd be interesting to hear the reasons why. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI
Kevin W. Wall kevin.w.w...@gmail.com writes: (Obviously some of these padding schemes such as OAEP are not suitable with symmetric ciphers. Or at least I don't think they are.) You'd be surprised at what JCE developers will implement just because they can, and what therefore gets used by application developers. I've seen RSA-CBC used on more than one occasion. (No, that's not a typo, RSA in CBC mode. The app developers wondered why it was so slow). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI
David Wagner d...@cs.berkeley.edu writes: (You could replace AES-CMAC with SHA1-HMAC, but why would you want to?) The answer to that depends on whether you need to support an existing base of crypto software and hardware. Even though (in this case) it's a new standard, it still requires support from the underlying crypto libraries. If little or none of those do AES-CMAC yet (I don't think Windows CryptoAPI does, only very recent versions of OpenSSL do... it's not looking good) then you'd want to stick with HMAC-SHA1. (Forestalling the inevitable but developers can implement AES-CMAC themselves from raw AES that I'm sure someone will follow up with, the target audience for this is web application developers, not cryptographers, so you need to give them something that works as required out of the box). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: RNG using AES CTR as encryption algorithm
Damien Miller d...@mindrot.org writes: The seems unlikely, since we don't use OpenSSL for AES-CTR in OpenSSH. I don't think OpenSSL even supports a CTR mode through its EVP API. I first saw it reported on the Putty bugs list [0], a good place to track interop problems with implementations since it's so widely used, which in turn points to https://bugzilla.mindrot.org/show_bug.cgi?id=1291: Connections from OpenSSH_4.5p1, OpenSSL 0.9.8d 28 Sep 2006 to OpenSSH_4.5p1, OpenSSL 0.9.8e 23 Feb 2007 using aes256-ctr fail with Bad packet length. The same problem occurs when using PuTTY 0.59 against the newer server. PuTTY users have reported this problem too, with servers on both FreeBSD and Linux, and with OpenSSH versions back to 4.0. In fact it was listed as closed and resolved by, uh, one Damien Miller :-). Peter. [0] Meaing bugs encountered while using Putty, not necessarily bugs in Putty. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: RNG using AES CTR as encryption algorithm
David Johnston d...@deadhat.com writes: Convincing yourself that you have implemented AES-CTR correctly usually involves first checking that your AES-ECB is correct, then putting the output of you counter construction into some other known good AES-CTR implementation and comparing the results with your implementation. I was just going to reply with a variation of this, if you're implementing a full protocol that uses AES-CTR (or any algorithm/mode for that matter), find other implementations that do it too and make sure that you can talk to them. In theory everyone could end up implementing it wrong, but that's somewhat unlikely. (This has already caught AES-CTR implementation bugs in the past, for example one particular version of OpenSSL 0.9.8 got AES-CTR keying wrong and it was noticed when SSH users couldn't connect to OpenSSH servers using this mode). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Ian G i...@systemics.com writes: If one is trying to solve the whole thing, then using the much-commented secure-bookmarks model would do this. Within the secure bookmark, record the user's certificate and cache enough info on the server's cert to deal with replacements (like, cert, name, CA). There's a variant of this, the site-specific browser (SSB), that takes you to (for example) your bank in a strongly sandboxed, hardened environment. This reduces the cognitive load on the user from a more or less impossible-to- follow set of instructions to only ever do your banking by clicking on this desktop icon. This isn't by any means a general solution, but by solving for the most common cases (your bank, Paypal, eBay, Amazon) you'd address a fairly large chunk of the problem. See Breaking out of the Browser to Defend Against Phishing Attacks by Smetters and Stewart for more details on this. Others have suggested some ideas, so I'll just add: the problem isn't IMO how to do it. There are lots of good ideas. Actually that does point out one problem, which I alluded to in my previous post: we have lots and lots of good ideas, but little hard data to indicate which ones will work and which won't, or which ones work better than others (although the cynical response to this might be that almost anything would work better than what we've got now). Specifically, there are a pile of papers along the lines of here's an experiment showing that what we're doing now doesn't work, here's a completely new security mechanism we've invented that involves redesigning the browser and server authentication back-end, and as a side-effect here are some UI ideas to go with it. What we don't have however is here's a real-world evaluation of various ideas that have been proposed for fixing what we already have built into browsers and servers. Unfortunately without this data we (including myself) are to some extent just people wanking around with their opinions [0]. It's also not certain how such data would be published. Which journal or conference would accept a paper with no new ideas in it, just a straightforward evaluation of existing material? Peter. [0] A Linus quote, brought about by a discussion on the difference between OS secheduler design and security design: the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is 'hard science'. The other one is 'people wanking around with their opinions'. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
Thor Lancelot Simon t...@rek.tjls.com writes:
I think we're largely talking past one another. As regards new horrible
problems I meant simply that if there _are_ new horrible problems_ such
that we need to switch away from SHA1 in the TLS PRF, the design mistakes
made in TLS 1.1 will make it much harder.
Well, let's move the TLS 1.2 aspect out of the discussion and look at the
underlying issues. If you're looking at this purely from a theoretical point
of view then it's possible that the ability to use SHA-2 in the PRF is an
improvement (it may also be a step backwards since you're now relying on a
single hash rather than the dual hash used in the original design). Since no-
one knows of any attacks, we don't know whether it's a step backwards, a step
forwards, or (most likely) a no-op.
However there's more to it than this. Once you've got the crypto sorted out,
you need to implement it, and then deploy it. So looking at the two options
you have:
Old: No known crypto weaknesses.
Interoperable with all deployed implementations.
Only one option, so not much to get wrong.
New: No known crypto weaknesses.
Interoperable with no deployed implementations.
Lots of flexibioity and options to get wrong.
Removing the common factors (the crypto portion) and the no-op terms
(interoperable with existing implementations) we're left with:
Old: -
New: Non-interoperable.
Complex - Likely to exhibit security flaws (from the maxim that
complexity is the enemy of security).
That's a rather high cost to pay just for the ability to make a crypto fashion
statement. Even if the ability to negotiate hash algorithms had been built in
from the start, this only removes the non-interoperability but doesn't remove
the complexity issue.
As I read Ben's comments, they were _advocating_ those kinds of design
mistakes, advocating hard-wiring particular algorithms or their parameter
sizes into protocols,
You keep asserting that this is a mistake, but in the absence of any
cryptographic argument in support, and with practical arguments against it, it
looks like a feature to me.
In fact, it is radically harder to replace an entire protocol, even with a
related one, than to drop a new algorithm into an existing, properly-designed
protocol.
A properly-designed security protocol is one that's both cryptographically
sound and simple enough that it's hard to get wrong (or at least relatively
easy to get right, admittedly not necessarily the same thing). Adding a pile
of complexity simply so you can make a crypto fashion statement doesn't seem
to be helping here.
If TLS 1.{0,1} had been designed to make the hash functions pluggagle
everywhere
... like that model of security protocol design IKEv1 was [0], then we'd have
all kinds of interop problems and quite probably security issues based on
exploitation of the unnecessary complexity of the protocol, for a net loss in
security and interoperability, and nothing gained.
Peter.
[0] Apologies to the IPsec folks on the list, just trying to illustrate the
point.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Steven Bellovin s...@cs.columbia.edu writes: This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? Good enough to satisfy security geeks, no, because no measure you take will ever be good enough. However if you want something that's good enough for most purposes then Camino has been doing something pretty close to this since it was first released (I'm not aware of any other browser that's even tried). When you're asked for credentials, the dialog rolls down out of the browser title bar in a hard-to-describe scrolling motion a bit like a supermarket till printout. In other words instead of a random popup appearing in front of you from who knows what source and asking for a password, you've got a direct visual link to the thing that the credentials are being requested for. You can obviously pepper and salt this as required (and I wouldn't dream of deploying something like this without getting UI folks to comment and test it on real users first), but doing this is a tractable UI design issue and not an intractable business-model/political/social/etc problem. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: I cannot see how you could create a bank web page without a web application framework (counting mod-php as a very primitive web application framework) and scripting and a database, which scripting and database has to know who it is is that logged in We really are talking about completely different things here. The scripting and whatnot has nothing to do with TLS or TLS auth mechanisms. The only thing you need to care about (if you really want to go this way) is channel binding. The information about which user, which database primary key is logged in, has to be passed up through one layer after another and from one process to another. Yeah, and that's what channel binding is for. The plumbing really is that complicated. Only if you deliberately choose to make it so. Read the RFCs I mentioned earlier. Because keep-alive usually fails for plumbing reasons, standard TLS usually does the PKI-based non-authentication dance every page, resulting in additional round trips, resulting in painfully bad performance for SSL web sites But TLS doesn't work like that. If it did, you'd get a cert popup every time you clicked on a link on a TLS-protected web site. Unless you somehow manage to flush the TLS session cache on the server (which seems unlikely unless you're DoS'ing it) there's no additional round-trip(s), or additional anything for that matter. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: [Incredibly complicated description of web scripting plumbing deleted] We seem to be talking about competely different things here. For a typical application, say online banking, I connect to my bank at www.bank.com or whatever, the browser requests my credential information, and the TLS-SRP or TLS-PSK channel is established. That's all. There's no web application framework and PHP and scripting and other stuff at all, in fact I can't even see how you'd inject this into the process. Further, if we do the SRP dance every single page, it is a huge performance hit, with many additional round trips. One loses about 20 percent of one's market share for each additional round trip. You only do it once when the TLS session is set up, it's exactly as for standard TLS except that instead of PKI-based non-authentication you use cryptographic mutual authentication. How do you get an SRP exchange for every web page? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: For password-authenticated key agreement such as TLS-SRP or TLS-PSK to work, login has to be in the chrome. Sure, but that's a relatively tractable UI problem (and see the comment below on Camino). Certificates on the other hand are an apparently intractable business, commercial, user education, programming, social, and technical problem. I'd much rather try and solve the former than the latter. The problem with password auth is that no browser (with the exception of Camino) has made even the most basic attempt to do the UI for this properly. In all cases the browser pops up a dialog box, unconnected to the underlying operation or web page, that says Gimme your password in one way or another. This could be coming from anywhere, the browser, Javascript on the web page, another web page, who knows where, but since everyone knows that passwords are insecure there's no point in expending any effort to try and make them secure, and that's been the status quo for fifteen years. What Camino does (and it's been awhile since I played with it, so I'll qualify that with what I hope it still does) is roll the password-entry box down out of the browser menu bar in a circular motion that's both hard to spoof and that unmistakably ties the credential-entry request both to the web page that it's associated with and to the browser rather than being some floating popup coming from who knows where or what. This can no doubt be nitpicked, but it's better than any other browser (that I've seen) does. More generally, I can't see that implementing client-side certs gives you much of anything in return for the massive amount of effort required because the problem is a lack of server auth, not of client auth. If I'm a phisher then I set up my bogus web site, get the user's certificate-based client auth message, throw it away, and report successful auth to the client. The browser then displays some sort of indicator that the high-security certificate auth was successful, and the user can feel more confident than usual in entering their credit card details. All you're doing is building even more substrate for phishing attacks. Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't, you're not getting any improvement, and potentially just making things worse by giving users a false sense of security. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: This, however, requires both client UI software, and an api to server side scripts such as PHP, Perl, or Python (the P in LAMP). On the server side, we need a request object in the script language that tells the script that this request comes from an entity that established a secure connection using shared secrets associated with such and such a database record entered in response to such and such a web page, an object to which the script generating a page can associate data that persists for the duration of the session - an object that has session scope rather than page scope, scope longer and broader than that of the thread of execution that generates the page, but shorter and narrower than that of the database record containing the shared secrets, a script accessible object that can only be associated with one server, one server side process and one server side thread at a time. This is non trivial to implement in an environment where servers are massively multithreaded, and often massively multiprocess. Ah, that is a good point, you now need the credential information present at the TLS level rather than the tunneled-protocol level (and a variation of this, although I think one that way overcomplicates things because it starts diverting into protocol redesign, is the channel binding problem (see RFC 5056 and, specific to TLS, draft-altman-tls-channel-bindings-05.txt)). On the other hand is this really such an insurmountable obstable? For client-cert usage you already need to perform a lookup based on a given cert (well, unless you blindly trust anyone displaying a cert coming from a particular CA or set of CAs, which I know some sites do), so now all you'd be doing is looking up a shared-secret value instead of a cert based on a client ID. I don't really see why you'd need complex scripting interfaces though, just return the shared-secret value associated with this ID in response to a request from the TLS layer. The only problem I can see is if you have an auth system built around is this authenticator valid rather than return the authenticator for this ID. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Ben Laurie b...@google.com writes: So, I've heard many complaints over the years about how the UI for client certificates sucks. Now's your chance to fix that problem - we're in the process of thinking about new client cert UI for Chrome, and welcome any input you might have. Obviously fully-baked proposals are more likely to get attention than vague suggestions. This is predicated on the assumption that it's possible to make certificates usable for general users. All the empirical evidence we have to date seems to point to this not being the case. Wouldn't it be better to say What can we do to replace certificates with something that works?, for example TLS-SRP or TLS-PSK? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Unattended reboots (was Re: The clouds are not random enough)
Arshad Noor arshad.n...@strongauth.com writes: If you (or anyone on this forum) know of technology that allows the application to gain access to the crypto-hardware after an unattended reboot - but can prevent an attacker from gaining access to those keys after compromising a legitimate ID on the machine - I'd welcome hearing about it. I talked to an auditor about this a while back, here's my summary of this: For auditing purposes the only thing that.s required for unattended restart is a mechanism to prevent an attacker from copying unprotected keying material from the machine. For example storing the key in a token plugged into the machine is generally considered sufficient because it gives you the ability to point to a physical security procedure that.s used to prevent the key (meaning the token that it.s held in) from being removed. This functions as an audit mechanism because it.ll be noticed if someone removes the token, which isn.t the case if someone copies a file containing the unprotected key from the machine. Hardware security modules (HSMs, a special-purpose crypto computing device capable of storing thousands of keys and performing encryption, signing, certificate management, and many other operations) are often used for this purpose, storing a single symmetric key in the HSM to meet audit requirements. If the HSM vendor has particularly good salespeople then they.ll sell the client at least two $20,000 HSMs (each storing a single key) for disaster recovery purposes. In other word's the target isn't necessarily what's good enough for security people, but what's good enough for the auditors, and the above was deemed good enough for the auditors. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: XML signature HMAC truncation authentication bypass
Jon Callas j...@callas.org writes: Okay, password-protected files would get it, too. I won't ask why you're sending password protected files to an agent. They're not technically password-protected files but pre-shared key (PSK) protected files, where the keys have a high level of entropy (presumably 128 bits, but I don't know the exact figure). So in this case the S2K isn't actually necessary because of the choice of password/PSK used. (Sorry, for non-OpenPGP folks S2K = string to key, a parameterised way of processing a password, for example by iterated hashing with a salt, into a key). By the way, do you think it's safe to phase out MD5? That will break all the PGP 2 users. The answer depends on what sort of user base you expect to have to support. In my case I disable things that I don't think get used much in betas and see if anyone complains. If no-one does, it remains disabled in the final release. Now if only I could rearrange this process so I didn't have to implement support for assorted practically-unused mechanisms in the first place... This is another interesting philosophical debate: What do other people do in terms of deprecating obsolete/insecure/little-used mechanisms? Deprecate by stealth? Flag day? Support it forever? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: The latest Flash vulnerability and monoculture
Perry E. Metzger pe...@piermont.com writes: This highlights an unfortunate instance of monoculture -- nearly everyone on the internet uses Flash for nearly all the video they watch, so just about everyone in the world is using a binary module from a single vendor day in, day out. There are quite a number of third-party video players that will render Flash video, are these using Adobe codecs or third-party H.263/264/VP6 ones? In theory you don't actually need to run Adobe code to view FLV's, but given the freewheeling nature of video players which often, um, borrow codecs from all over the place, it's hard to tell what you're actually getting. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
