RE: question re practical use of secret sharing
Peter Gutmann writes: Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? It's available as part of other products (e.g. nCipher do it for keying their HSMs) Do you mean the k of n operator cards? For those, I don't think nCipher is using real secret sharing. I would guess that the HSM knows the secret(s), and counts the operator cards that are submitted. There is a financial standard for distributing ZCMK's (Zone Control Master Keys) that splits the ZCMK up into three pieces the same length as the original. This is 3 of 3. nCipher and other HSM vendors support this, and it's used wtih a little hand-held PIN pad. I guess this would count as an example of products that use secret sharing. Perhaps this is what you were referring to. gh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Gutmann Sent: Thursday, June 21, 2007 6:57 AM To: [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: Re: question re practical use of secret sharing 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? 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: question re practical use of secret sharing
Actually I worked on a project recently that had this scenario. Paramedic team picks up heart attack/stroke/serious accident patient. The paramedic tending the patient is using a laptop to record EKG or other electronic medical process. Even with the siren on they get in a serious accident that puts the paramedic in a coma due to a concussion. The laptop with the data is broken. At the hospital they yank the hard drive and using an adapter cable mount it on another computer. However, since medical data is considered personal and private data the hard drive is encrypted. The patient, especially if a stroke victim, needs to have his condition understood immediately. Yes, they can do the same tests again, but that does not give them a baseline to compare to: Is the patient getting worse, staying the same, or maybe even improving? With a stroke victim there is a very short window for doing some types of treatment. How do you recover the data? Two solutions were considered, one was secret sharing and the other was StrongAuth's commercial version of the open source StrongKey. The StrongAuth approach was better than the secret sharing but both were way ahead of the next possible choice. The primary reason that the StrongAuth approach would work better is that the medical data would be stored an a folder/partition that every person with the same level of access rights or higher could access the data with their own authentication via a stored certificate. This would mean there would be many people's certificate stored on the drive, but being relatively small this would not pose a problem. The secret sharing was next best because anyone at the hospital could call a central paging system that would page all security people with the number to login to. If enough shares were created - we were thinking 99+ for a major medical system - then the minimum needed - we were thinking three - to recover the key would be available 24/7/366 to generate the needed key to allow access. Both would work, but in this scenario, the local certificate would be faster by several minutes. If StrongAuth did not exist, then the secret sharing approach would be the only approach that could be made to work fast enough. Granted this seems like a corner case, but, trust me, this scenario happens several times a year in the USA. What with medical diagnosis and treatment being pushed closer to the scene of the emergency this is likely to become more common. Except for time critical events, secret sharing is the easiest to deploy and use in a robust way but there are very few, none that I could find, implementations of it that would have enough shares to cover vacations, out of range, and other vagaries of human existence. BTW, on the net is a demo of secret sharing: http://point-at-infinity.org//demo.html Allen 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? 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: question re practical use of secret sharing
James A. Donald: Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? Peter Gutmann 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. There is no market, zero, for stand alone crypto of any kind. Cryptographic solutions should be embedded invisibly in products that do tasks for the user. The purpose of cryptography is to stop such products from invisibly doing tasks for an adversary. Since the attack is generally invisible, one cannot expect the user to use a visible addon product to protect against the attack. - 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: question re practical use of secret sharing
D. K. Smetters [EMAIL PROTECTED] writes: 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. I think that's the perfect summary of the problem with threshold schemes. The processes they involve is simply too complex both to model mentally for users and to build an interface to. If you look at the nCipher manuals (for example http://active.ncipher.com/documentation/nCSS/win/user/nShield_Admin.pdf), you can see that they're really struggling to communicate the operational details to users, and I've heard from users that it's so hard to use that few bother. This isn't due to any failing of nCipher, 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. When we were mulling it over to see whether it was worth standardising, we tried to come up with a general-purpose programming API for it. We were working at the very geeky crypto toolkit API level (where you're allowed to be somewhat non-user-friendly), not at the UI level. Now if you compare a standard crypto-op: encrypt( data, length, key ); or: sign( message, length, key ); with what's needed to manage a threshold scheme: add share 7 of a total of 12, of which at least 8 are needed, returning an error indicating that more shares are required with a side order of: using 3 existing valid shares, vote out a rogue share and regenerate a fresh share to replace it then you start coming up with an API with abstract data-access capabilities at a complexity level of something like ODBC. (ODBC is the most appropriate API model I could come up with without thinking about it for too long, obviously you don't need all of ODBC but the data representation and access model was a reasonably good fit). So that lead to two questions: 1. Who would want to implement and use an ODBC-complexity-level API just to protect a key? 2. How are you going to fit a UI to that? (This is the real killer, even if you come up with some API to do (1), there's probably no effectively usable way to do (2)). At that de facto QED the discussion more or less ended. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
Alexander Klimov wrote: So if one xors a Linux iso image and some movie, it is quite hard to claim that the result is copyright-protected. Why? A copyright-protected work is still copyright-protected, encrypted or not. It is just as with any reversible encoding of a copyright- protected work, such as magnetic domain encoding when storing it in a hard disk. Now, if you pass a copyright-protected work through an irreversible hash function, it would be hard to claim the result to be copyright-protected. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
On Jun 13, 2007, at 4:47 AM, Charles Jackson wrote: A quick question. Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? PGP. http://www.pgp.com/ I can tell you more gory details than you're probably interested in. But you can go get a free trial and play with it. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
[EMAIL PROTECTED] D. K. Smetters [EMAIL PROTECTED] writes: 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. I think that's the perfect summary of the problem with threshold schemes. The processes they involve is simply too complex both to model mentally for users and to build an interface to. Heck, even normal key management seems to be too much. Most real world secure systems I seen have a leap of faith aspect to them when distributing the first key (such as a CA or a login server's public key). Often MITM scenarios are not properly considered when distributing the session keys/ certificates. Software ease-of-use/automation trumps properly done key management/user enrollment. It's a pity because often millions of people start using them before the serious problems start to crop up (like thievery or illegal wiretapping) and then it's too late to retrofit them properly (for example Skype seems to have made these types of mistakes). - Alex - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
Very interesting discussion. I bring a different angle to the very topic of discussion (practical use). See below, after the quotes which I fully agree. Peter Gutmann wrote: D. K. Smetters [EMAIL PROTECTED] writes: 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. I think that's the perfect summary of the problem with threshold schemes. The processes they involve is simply too complex both to model mentally for users and to build an interface to. [...] When we were mulling it over to see whether it was worth standardising, we tried to come up with a general-purpose programming API for it. [...] working at the very geeky crypto toolkit API level (where you're allowed to be So that lead to two questions: 1. Who would want to implement and use an ODBC-complexity-level API just to protect a key? 2. How are you going to fit a UI to that? (This is the real killer, even if you come up with some API to do (1), there's probably no effectively usable way to do (2)). At that de facto QED the discussion more or less ended. Peter. Here is a different perspective. Forget about mathematics (who wants to go farther than 2 out of 3, 3 out of 4, and 2 out of 4). Forget about an API: think first of a potential application area. Forget about HCI (Human Computer Interface): focus on the control/liability allowed/implied by a key share and the administrative procedures. Forget about processors and computers altogether! If I didn't lose you yet, think of secret sharing for the *long-term cryptographic key material* for DNSSEC support at the root. I.e. share the control over delegation of DNSSEC *routine* signature operations (to IANA staff in the foreseeable future) among secret sharing entities, say USG NTIA, an European entity, and a third one elsewhere. Store the key shares on paper sheets of bar codes - the user interface is a safe box for the secure hardware, and a diplomatic briefcase for transport layer. Actually, secret sharing implies significant procedural overhead for key management, and hence may find applications only in master keys of some orgnizations. I did propose a scheme where the above principles are implicitly put forward, i.e. TAKREM for DNSSEC (root) trust anchor key rollover. The above long-term cryptographic key material is specified in the TAKREM documentation (perhaps other routine public key cryptoperiod management schemes might use the same principles for secret sharing). From some of those who develop interoperability specifications (i.e. IETF participants) I was called a patent troll. From those organizations who control the Internet, i.e. USG NTIA, Verisign, and ICANN, I seem to be nobody. Hence the proposal made little progress. In summary, to answer the question practical use of secret sharing, I don't see it in my crystal ball. Nonetheless, control of DNSSEC root signature key would be a good candidate application area for secret sharing. Admittedly, the above change in perspective does not solve the difficulty people have in managing keys in general -- it merely shifts it from trusted system administrators to diplomats and like individuals. (A DHS sponsored study even ignored or downplayed mere split key storage for protecting the DNSSEC root private key.) Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
There is a opensource implementation available: http://point-at-infinity.org// On 6/13/07, Charles Jackson [EMAIL PROTECTED] wrote: A quick question. Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
On Fri, 22 Jun 2007, Peter Gutmann wrote: 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). http://monolith.sourceforge.net/: Monolith is a simple tool that takes two arbitrary binary files (called a Basis file and an Element file) and munges them together to produce a Mono binary file (with a .mono extension). Monolith can also reconstruct an Element file from a Basis file and a Mono file. So if one xors a Linux iso image and some movie, it is quite hard to claim that the result is copyright-protected. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
RSA's BSAFE 6.2.1.0 supports Bloom-Shamir secret sharing. Peter Trei Principal Engineer RSA: the Security Division of EMC. Disclaimer: I am not a spokesperson for RSA or EMC. -Original Message- Charles Jackson asks: A quick question. Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
