Re: Is cryptography where security took the wrong branch?
> Eric Rescorla wrote: Ian Grigg <[EMAIL PROTECTED]> writes: I'm almost convinced that WEP is a failure, but I think it retains some residual value. I agree. After all, I occasionally come upon a network I'd like to use and WEP stops me cause I'm too lazy. On the other hand, MAC restrictions would have done just as well for that. I find WEP very useful for one thing -- given the habit of many wireless clients to opportunistically jump onto any network they happen to find, turning on WEP keeps users from accidentally "falling" onto networks by mistake. This saves a lot of confusion if you have the occaisional research network with say, different firewalling properties than a user might expect, or one that doesn't actually route to the outside world. And it's easier to manage than MAC filtering. --d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
Peter Gutmann wrote: "Charles Jackson" <[EMAIL PROTECTED]> writes: Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? I believe at least some versions of PGP might have supported secret sharing for key backup. Secret sharing is also fundamentally less interesting than full-bore threshold cryptography (using the fragments of a key without reassembling them first). We built a threshold crypto-based certification authority at CertCo a number of years ago, which was used for some very high security root CAs. However, given the difficulty people have in managing keys in general, building effective systems that allow them to manage key fragments is beyond the range of most current commercial products. It is something we use regularly in research systems, but only with a very careful eye to both our motivation (there has to be, as Peter points out, some good user reason for it), and ultimate system usability. --Diana It's available as part of other products (e.g. nCipher do it for keying their HSMs), but I don't know of any product that just does... secret sharing. What would be the user interface for such an application? What would be the target audience? (I mean a real target audience, not some hypothesised scenario). (This is actually a serious question. I talked with some crypto guys a few years ago about doing a standard for secret sharing, but to do that we had to come up with some general usage model for it rather than just one particular application-specific solution, and couldn't). Besides that, user demand for it was practically nonexistent... no, it was completely nonexistent, apart from a few highly specialised custom uses we couldn't even find someone to use as a guinea pig for testing, and the existing specialised users already had specialised solutions of their own for handling it. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann wrote: For existing apps with habituated users, so am I. So how about the following strawman: Take an existing browser (say Firefox), brand it as some special- case secure online banking browser, and use the "new developments" solution above, i.e. it only talks mutual-auth challenge-response crypto and nothing else. At that point you've reduced "Reformat user and reinstall browsing habits" to "Train users to only use safe-browser when they do their banking, i.e. 'Never enter banking details using anything other than safe-browser'". Even if you only get a subset of users doing this, it's still a massive attack surface reduction because you've raised the bar from any idiot who buys a phishing kit to having to perform a man-in-the-browser attack. We did a version of this for CEAS this year (paper here: http://www.parc.com/research/publications/details.php?id=6496). I agree, I think it's not hard to come up with an architecture that increases user security, while reducing the amount they have to learn. Though, as per Perry's comment, you do need to be able to say that *some* (not all) of the software on your machine is not totally borked... (an interesting question is: how much, and what). --Diana - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is this the first ever practically-deployed use of a threshold scheme?
Jonathan Katz wrote: On Sat, 31 Jul 2010, Jakob Schlyter wrote: On 31 jul 2010, at 08.44, Peter Gutmann wrote: 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? The DNS root key is stored in HSMs. The key backups (maintained by ICANN) are encrypted with a storage master key (SMK), created inside the HSM and then split among 7 people (aka "Recovery Key Share Holders"). To recover the SMK in case of all 4 HSMs going bad, 5 of 7 key shares are required. (https://www.iana.org/dnssec/icann-dps.txt section 5.2.4) According to the FIPS 140-2 Security Policy of the HSM, an AEP Keyper, the M-of-N key split is done using a La Grange interpolating Polynomial. I'd be happy to answer any additional questions, jakob (part of the team who designed and implemented this) This is "just" Shamir secret sharing, not "real" threshold cryptography. (In a threshold cryptosystem, the shares would be used in a protocol to perform the desired cryptographic operation [e.g., signing] without ever reconstructing the real secret.) Has real threshold cryptography never been used anywhere? CertCo (RIP) built a Certification Authority software product that used "real" threshold cryptography. Key shares for a k of n scheme (where k and n were chosen at key split time) were stored in hardware crypto tokens, and signatures were generated by having k tokens generate partial signatures and then combining them into a "regular" RSA sig. The system was deployed as the SET root CA for some time; we did try to sell it as a regular software product, but (corporate) political issues made that somewhat challenging. I honestly don't remember whether it was deployed by anyone else for anything other than SET, but it may be that one of the (many) other CertCo alumni on this list might. The original CertCo CA software used pretty simple threshold crypto (I can provide paper refs for the particular schemes we used if anyone really wants them), but by the time I left we had worked on verifiable schemes (where you can verify the partial sigs independently), proactivization (re-sharing to change k or n, or remove bad players), and so on. The deployed system did not implement distributed key generation, which had just appeared in the literature at that time -- the key was generated on one token, and then split; the key generation token was then intended to be destroyed. Although the system was designed to be used in a globally distributed fashion, with automated systems for sending work (things to sign) to sites holding key shares (where each signing request was signed by an RA to authorize it), and then collecting and recombining the partial sigs, it turned out to be way too hard to use that way. I don't know if it was ever deployed in a truly geographically distributed configuration, rather than having all the shares (except for backups) kept at one site. (And as a result, I started working on usability of security :-). Shortly after the last CertCo CA, Victor Shoup published a new threshold RSA scheme that made them much simpler to incorporate into deployable systems; building a system that uses "real" threshold crypto would be pretty easy these days if one wanted to. If nothing else, it's a great example for cryptographers of how small changes in the algebraic formulation of something can have large impact on how easy it is to build into systems. --Diana Smetters - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
