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: Free Rootkit with Every New Intel Machine
[EMAIL PROTECTED] said: With TPMs it's a bit different, they're absent from the hardware by default in case you're referring to the TCPA (trusted computing platform alliance) TPM.. my understanding from a person active in the NEA working group (IETF) is that TPMs these days come along for free because they're included on-die in at least one of said chips. I don't recall whether he said it was the network interface (NIC) and/or one of the others. So anyway, he said ...enterprise-class systems (eg Dell Latitudes) mostly all already contain, TPMs and various network gear manufacturers have boxes that speak to them already, and NEA is just trying to standardize the protocols... I've noticed my latitude systems do in fact have a bios option for enabling/disabling their TPMs. (mine are disabled) the way in that IT depts ensure that vic...er...employees don't turn 'em off (as I understand it) is they set the BIOS admin password on their assets (computers) before their give them out. =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
On Jun 20, 2007, at 8:41 PM, Steven M. Bellovin wrote: According to the AP (which is quoting Le Monde), French government defense experts have advised officials in France's corridors of power to stop using BlackBerry, reportedly to avoid snooping by U.S. intelligence agencies. That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. In fact, I found this text on Blackberry's site: There have been rumors for years that the BlackBerry protocol is compromised by some government or other. I've heard them for years. Ultimately, no one knows, and there's no way to know. It boils down to whether you trust RIM or not. There is a PGP software package for the BlackBerry that will further encrypt the content before it's sent out. I use it, and it's quite nice. It cooperates really nicely with one of my PGP Universal servers, as well. It's one of the best integrations of crypto into a mail package I've ever seen. However, you still have to trust RIM. I've never seen any of the code, myself. and to my knowledge no one outside RIM has. There are any number of ways that the implementation could be compromised, with or without RIM's knowledge. Paranoia is the *unwarranted* belief that people are out to get you. The warranted belief that people are out to get you is caution. Personally, I think that this is pure paranoid rumor and innuendo. That doesn't mean it's wrong, it just means it's unwarranted. Last week, I got sent a posting on a web site that someone made that said that he had secret knowledge that the USG could break RSA for all key sizes that anyone uses, so you should just stop using any cryptosystem that uses it. Of course, he couldn't tell us anything more to protect the position of the person who told him that. I said that if someone told you that an unidentified friend had secret knowledge that banks were unsafe and so you shouldn't keep keep your money there, your I'm being scammed hairs on the back of your neck would stand up. But if some unidentified someone tells you that the crypto's bad, it's met with complete credulity. I have no doubt that people in various governments want to spy on high-ranking French. Duh. But what's more likely, that there are secret government compromises of security, or that there's a secret disinformation campaign with the goal of convincing these people that the crypto is compromised. Of course, the really delicious theory is that they've compromised the crypto and then started the disinformation campaign in order to get people like me to discredit the disinformation campaign and thus reassure people that the crypto isn't broken, when in fact it is. Is this paranoid, or merely cautious? Jon - 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]
interesting paper on eprint archive
The consensus from a few of my friends is that this paper (by Warren Smith) is a bit eccentrically written but not obviously flawed. Whether it is of any practical importance at all remains to be seen -- there may be no way to apply the results. http://eprint.iacr.org/2007/248 Abstract. We describe a new simple but more powerful form of linear cryptanalysis. It appears to break AES (and undoubtably other cryptosystems too, e.g. SKIPJACK). The break is ``nonconstructive,'' i.e. we make it plausible (e.g. prove it in certain approximate probabilistic models) that a small algorithm for quickly determining AES-256 keys from plaintext-ciphertext pairs exists -- but without constructing the algorithm. The attack's runtime is comparable to performing $64^w$ encryptions where $w$ is the (unknown) minimum Hamming weight in certain binary linear error-correcting codes (BLECCs) associated with AES-256. If $w 43$ then our attack is faster than exhaustive key search; probably $w 10$. (Also there should be ciphertext-only attacks if the plaintext is natural English.) -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
Victor Duchovni wrote: Quantum Cryptography or Quantum Computing (i.e. cryptanysis)? - Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). I do not really agree on this statement. There are ongoing projects, that I know of, that are actually working on maximizing communication throughput (which is currently not very good) on encrypted channels and minimizing costs of involved equipment. AFAIK, one great advantage of quantum crypto is in the area of key-exchange when establishing a secure communication. I guess quantum crypto is definitely not fiction (Anyhow I do not know if it has already been used somewhere... ). Later, -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063Work Phone: +1 (603) 646-9179 --o smime.p7s Description: S/MIME Cryptographic Signature
Re: Quantum Cryptography
- Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). Well that is a broad (and maybe unfair) statement. Quantum Key Distribution (QKD) solves an applied problem of secure key distribution. It may not be able to ensure unconditional secrecy during key exchange, but it can detect any eavesdropping. Once eavesdropping is detected, the key can be discarded. saqib http://security-basics.blogspot.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On Thu, Jun 21, 2007 at 06:00:48PM +0100, Richard Clayton wrote: (a) the EU legislation was actually passed well over a year ago http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2006/l_105/l_10520060413en00540063.pdf It is not national law yet. I'm only concerned about when I have to deal with it personally. and applies to service providers so random endpoints will be The pending legislation is stated broadly enough to include anyone with a proxy or a mix cascade, company or private body, for-profit or non-profit. It threatens up to half a megaeuro penalty and up to two years in jail. unlikely to be caught by its requirements. Any random endpoints will be passing through the ISP, and hence subject to retention. An ad hoc IPsec or VPN tunnel setup will make data analysis more difficult, especially if there's traffic background (P2P, etc). So what's the state in ad hoc IPsec/VPN setup for any end points? (b) what the Directive exactly means is anyone's guess (the wording shows a deep failure to understand how the Internet works), and it is entirely clear that it will in practice mean different things in different EU countries. I've been told this legislation will be used by several persons within BKA etc. to harass Tor operators. This is not a guess; I'm not sure how reliable that source is, however. In the UK it's likely to only apply to large public ISPs -- and retention will be restricted to records of who used which IP address, email server records, and possibly web cache logs (possibly not, since web caches may not be economic if the logs have to be retained)... The financial burden is completely on the side of the providers. ... the wikipedia page on the topic http://en.wikipedia.org/wiki/Data_retention ... has information for other countries that looks fairly plausible from what I know about their plans. Unfortunately, I know more about the plans than I ever wished. Note that the Directive also applies to phone calls ... and the It also applies to mobile phone location in the cell. transposition of that into national laws is supposed to be completed by October 2007; most countries have until March 2009 for Internet logs Apparently, Germany will implement Internet connection retention by end of the year/beginning of 2008 latest. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
Steven M. Bellovin wrote: That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. Doesn't this run into the common problem of supposedly it's secure, but they're not offering the source, just like with e.g. Skype, TPM RNGs, all commercial hardware security modules that I'm aware of, etc? Personally, I found a SymbianOS phone with a full keyboard that's lighter, thinner and more stylish than the Blackberry, runs Python and exposes most of the phone functionality to it through a set of APIs, and is happy to grab my mail via IMAP+SSL. With an unlimited data plan, who cares if it's pull instead of push e-mail? -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Thu, Jun 21, 2007 at 01:20:35PM -0400, Victor Duchovni wrote: Quantum Cryptography or Quantum Computing (i.e. cryptanysis)? - Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). - Quantum Computing is science fiction. Some science fiction eventually becomes reality. A nice blog to follow here is Shtetl-Optimized: http://www.scottaaronson.com/blog/ -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - 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: Quantum Cryptography
On Thu, Jun 21, 2007 at 10:59:14AM -0700, Ali, Saqib wrote: - Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). Well that is a broad (and maybe unfair) statement. Quantum Key Distribution (QKD) solves an applied problem of secure key distribution. It may not be able to ensure unconditional secrecy during key exchange, but it can detect any eavesdropping. Once eavesdropping is detected, the key can be discarded. Secure in what sense? Did I miss reading about the part of QKD that addresses MITM (just as plausible IMHO with fixed circuits as passive eavesdropping)? Once QKD is augmented with authentication to address MITM, the Q seems entirely irrelevant. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
Massimiliano Pala [EMAIL PROTECTED] writes: Victor Duchovni wrote: Quantum Cryptography or Quantum Computing (i.e. cryptanysis)? - Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). I do not really agree on this statement. There are ongoing projects, that I know of, that are actually working on maximizing communication throughput (which is currently not very good) on encrypted channels and minimizing costs of involved equipment. AFAIK, one great advantage of quantum crypto is in the area of key-exchange when establishing a secure communication. I guess quantum crypto is definitely not fiction (Anyhow I do not know if it has already been used somewhere... ). Quantum cryptography is useless. Victor is completely correct here. Quantum crypto provides you with a slow way of getting a one time pad (of sorts) that you cannot authenticate and thus cannot trust, between two endpoints only, and it does it at extreme expense. Why do I say that you cannot authenticate? Because although you can tell that no one eavesdropped in on the line, you have no way of knowing that no one cut the fiber in two and put two such boxes in between. You know that no one eavesdropped, but not who you are talking to. Various physics types who I explain this to generally do not understand what I'm talking about at first blush because they only consider the problem of eavesdropping -- the notion that you also need to verify who the guy at the other end is never occurs to them because they aren't security people. The fact that the attacker might not even bother to eavesdrop and could simply insert himself into the communication stream never occurs to the proponents. So, to fix the man-in-the-middle problem, you have to layer an authentication technology on top. Unfortunately, the ones we have are all conventional crypto -- perhaps a MAC of some sort. At which point, you're trusting conventional crypto for your security, so why bother? Conventional crypto is nearly free. This brings up another issue. Quantum crypto is exceptionally expensive, and is virtually undeployable. To provide security that, in a practical sense, is no better than what you can get from high key length conventional ciphers, you spend vast amounts on end system equipment, rent a dedicated dark fiber link between two locations that can't be arbitrarily far apart, and in the end, you have two machines that can talk securely in a world where one needs thousands or millions of machines to talk securely to any one of the other machines. The phone network and internet exist for a reason -- people want communication networks, not a string between two cans between each other's homes. They need NxN communication, not 1-1 communication. Building the N^2 array of dark fibers and quantum crypto boxes between lots of machines is, of course, utterly impractical and always will be. Of course, even if you could, you would still need out of band key distribution and a MAC to know that no one had man-in-the-middled your links. Again, why bother? Now, lets consider the alternative. In a practical sense, no one rational worries on a day to day basis that their security is going to be compromised because someone has a magic box that decrypts 256 bit AES in 12 seconds flat. The crypto we already have is more than good enough. Quantum Crypto exists on the mistaken premise that people are worried about their ciphers being broken and that this is the main issue in security. It is not. Having your ciphers broken is not even remotely the main issue for most installations. What people worry about in the real world are design flaws, programming errors, human interface problems that make things like phishing possible, and whether or not the $12-an-hour security guard at your data center will happily take a $5000 bribe to let someone at your equipment for an hour. Quantum Key Distribution solves none of those issues at all. The issue it does solve is a non-issue -- we already have 256 bit keyed AES if you need it. Quantum Crypto does what it says it does, but it is a commercially worthless invention, like an 800 pound wristwatch that is 20% more accurate than normal wristwatches but which is completely wrong one day in seven, or like a $20,000,000 tube of toothpaste that tastes slightly better but causes your teeth to explode one time in every 400. Even if the watch is marginally more accurate, no one will wear it. Even if the toothpaste tastes slightly better, no one will buy it. Neither invention solves a real problem from the real world. Quantum Crypto was invented by physicists who understand physics well but have no understanding of security. It does what it claims to do, but what it claims to do is of no use to anyone. Quantum Crypto does nothing for at all for the things people actually need solved, and for what it does do, it costs vastly too much. It is a lead balloon, a jet
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: Quantum Cryptography
| - Quantum Cryptography is fiction (strictly claims that it solves |an applied problem are fiction, indisputably interesting Physics). | | Well that is a broad (and maybe unfair) statement. | | Quantum Key Distribution (QKD) solves an applied problem of secure key | distribution. It may not be able to ensure unconditional secrecy | during key exchange, but it can detect any eavesdropping. Once | eavesdropping is detected, the key can be discarded. | | Secure in what sense? Did I miss reading about the part of QKD that | addresses MITM (just as plausible IMHO with fixed circuits as passive | eavesdropping)? | | Once QKD is augmented with authentication to address MITM, the Q | seems entirely irrelevant. The unique thing the Q provides is the ability to detect eaves- dropping. I think a couple of weeks ago I forwarded a pointer to a paper showing that there were some limits to this ability, but even so, this is a unique feature that no combination of existing primitives can provide. One can argue about what this adds. The current approach of the QKD efforts is to assume that physical constraints are sufficient to block MITM, while quantum contraints block passive listening (which is assumed not to be preventable using physical constraints). It's the combination that gives you security. One can argue about the reasonableness of this model - particularly about the ability of physical limitations to block MITM. It does move the center of the problem, however - and into a region (physical protection) in which there is much more experience and perhaps some better intuition. Valid or not, it certainly is easier to give people the warm fuzzies by talking about physical protection than by talking about math In the other direction, whether the ability to detect eavesdropping lets you do anything interesting is, I think, an open question. I wouldn't dismiss it out of hand. There's an old paper that posits related primitive, Verify Once Memory: Present it with a set of bits, and it answers either Yes, that's the value stored in me or No, wrong value. In either case, *the stored bits are irrevokably scrambled*. (One could, in principle, build such a thing with quantum bits, but beyond the general suggestions in the original paper, no one has worked out how to do this in detail.) The paper uses this as a primitive to construct unforgeable subway tokens: Even if you buy a whole bunch of valid tokens, and get hold of a whole bunch of used ones, you have no way to construct a new one. (One could probably go further - I don't recall if the paper does - and have a do the two of you match primitive, which would use quantum bits in both the token and the token validator. Then even if you had a token validator, you couldn't create new tokens. Obviously, in this case you don't want to scramble the validator.) -- Jerry | -- | | /\ ASCII RIBBON NOTICE: If received in error, | \ / CAMPAIGN Victor Duchovni please destroy and notify | X AGAINST IT Security, sender. Sender does not waive | / \ HTML MAILMorgan Stanley confidentiality or privilege, |and use is prohibited. | | - | 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: Quantum Cryptography
At 10:59 AM -0700 6/21/07, Ali, Saqib wrote: - Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). Well that is a broad (and maybe unfair) statement. Quantum Key Distribution (QKD) solves an applied problem of secure key distribution. It may not be able to ensure unconditional secrecy during key exchange, but it can detect any eavesdropping. Once eavesdropping is detected, the key can be discarded. ...whereas the key distribution systems we have aren't affected by eavesdropping unless the attacker has the ability to perform 2^128 or more operations, which he doesn't. Which part of the word useless is not apparent here? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On 6/22/07, Eugen Leitl [EMAIL PROTECTED] wrote: So what's the state in ad hoc IPsec/VPN setup for any end points? The Linux FreeS/WAN project was working on opportunistic encryption. The general idea is that if you use keys in DNS to authenticate gateways and IPsec for secure tunnels then any two machines can communicate securely without their administrators needing to talk to each other or to set up specific pre-arranged tunnels. http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/glossary.html#carpediem http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html There is an RFC based on that work: ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt The FreeS/WAN project has ended. I do no know if the follow-on projects, openswan.org and strongswan.org, support OE. -- Sandy Harris Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Fri, Jun 22, 2007 at 11:33:38AM -0400, Leichter, Jerry wrote: | Secure in what sense? Did I miss reading about the part of QKD that | addresses MITM (just as plausible IMHO with fixed circuits as passive | eavesdropping)? | | Once QKD is augmented with authentication to address MITM, the Q | seems entirely irrelevant. The unique thing the Q provides is the ability to detect eaves- dropping. If I want to encrypt a fixed circuit, I assume that eavesdropping is omni-present, and furthermore don't want to be constrained to transmit only when the eavesdroppers have chosen to take a lunch break. One can argue about what this adds. Warm fuzzies? The current approach of the QKD efforts is to assume that physical constraints are sufficient to block MITM. An interesting assumption. It does move the center of the problem, however - and into a region (physical protection) in which there is much more experience and perhaps some better intuition. I would conjecture that a lot more people grasp undergraduate mathematics than undergraduate quantum mechanics... Valid or not, it certainly is easier to give people the warm fuzzies by talking about physical protection than by talking about math Warm fuzzies is not in conflict with fiction. In the other direction, whether the ability to detect eavesdropping lets you do anything interesting is, I think, an open question. I wouldn't dismiss it out of hand. There's an old paper that posits related primitive, Verify Once Memory: Present it with a set of bits, and it answers either Yes, that's the value stored in me or No, wrong value. Suppose I install a fake subway entrace, and MITM all the interactions between the victim's card and the real turnstile where I have a card that proxies the victims interactions with the fake terminal. Is the system still secure? Likely not, I would bet The threat model was card forgery, not MITM. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
Leichter, Jerry [EMAIL PROTECTED] writes: | - Quantum Cryptography is fiction (strictly claims that it solves |an applied problem are fiction, indisputably interesting Physics). | | Well that is a broad (and maybe unfair) statement. | | Quantum Key Distribution (QKD) solves an applied problem of secure key | distribution. It may not be able to ensure unconditional secrecy | during key exchange, but it can detect any eavesdropping. Once | eavesdropping is detected, the key can be discarded. | | Secure in what sense? Did I miss reading about the part of QKD that | addresses MITM (just as plausible IMHO with fixed circuits as passive | eavesdropping)? | | Once QKD is augmented with authentication to address MITM, the Q | seems entirely irrelevant. The unique thing the Q provides is the ability to detect eaves- dropping. I think a couple of weeks ago I forwarded a pointer to a paper showing that there were some limits to this ability, but even so, this is a unique feature that no combination of existing primitives can provide. One can argue about what this adds. If it cost almost nothing, it would be a neat frill to have. When it increases the cost of encrypting a link by a factor of four to six orders of magnitude while still requiring all the old security systems you had before, it is pretty uninteresting. The current approach of the QKD efforts is to assume that physical constraints are sufficient to block MITM, [...] One can argue about the reasonableness of this model - particularly about the ability of physical limitations to block MITM. It does move the center of the problem, however - and into a region (physical protection) in which there is much more experience and perhaps some better intuition. Indeed it does. We have a lot of experience with securing links that go for hundreds of km, and the experience tells us that we can't do it in the real world. It would be one thing if experience said that attackers can be easily found and stopped on long range physical links, but we know that they can't, so why are we even thinking about it this way? Besides, companies like MagiQ don't say we're giving you unconditional security against eavesdropping provided your prayers that no one MITMs you are granted, they claim that they are providing you with actual unconditional security. They clearly are not. In the other direction, whether the ability to detect eavesdropping lets you do anything interesting is, I think, an open question. I wouldn't dismiss it out of hand. As you know, most of us argue you should simply assume you're being eavesdropped on and design security so that you don't care. It is much simpler, much less expensive, and much more robust. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
A secure Internet requires a secure network protocol
A secure Internet requires a secure network protocol http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html from above: Implementing -- and requiring -- stronger authentication and cryptography standards is the next step toward a new Internet ... snip ... i would contend that majority of exploits are attacks on (vulnerable) end-points ... not directly involving any actual network protocol or cryptography; this includes (updated) variations on old-time social engineering ... which has some relation to authentication (between end-points) ... but on par with crooks using the telephone to call people and convince them of one thing or another (and then suggesting that encrypting the telephone call transmission would eliminate the problem). one of the things seen in various of the SSL (authentication) vulnerabilities ... are attackers being able to (authenticate) prove who they claim to be ... however, who they claim to be for SSL authentication ... and who they claim to be for their social engineering attacks ... may not be exactly the same. As before, one of the largest class of attacks (not restricted to internet) are against information related to payment transactions and which (largely because of weak authentication in unrelated parts of the infrastructure) is then turned around and relatively easily used for fraudulent financial transactions. misc. past posts on the theme of naked transactions. http://www.garlic.com/~lynn/subintegrity.html#payment - 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: ad hoc IPsec or similiar
At 11:52 PM +0800 6/22/07, Sandy Harris wrote: On 6/22/07, Eugen Leitl [EMAIL PROTECTED] wrote: So what's the state in ad hoc IPsec/VPN setup for any end points? The Linux FreeS/WAN project was working on opportunistic encryption. The general idea is that if you use keys in DNS to authenticate gateways and IPsec for secure tunnels then any two machines can communicate securely without their administrators needing to talk to each other or to set up specific pre-arranged tunnels. http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/glossary.html#carpediem http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html There is an RFC based on that work: ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt The FreeS/WAN project has ended. I do no know if the follow-on projects, openswan.org and strongswan.org, support OE. Note that that RFC is Informational only. There were a bunch of perceived issues with it, although I think they were more purity disagreements than anything. FWIW, if you do *not* care about man-in-the-middle attacks (called active attacks in RFC 4322), the solution is much, much simpler than what is given in RFC 4322: everyone on the Internet agrees on a single pre-shared secret and uses it. You lose any authentication from IPsec, but if all you want is an encrypted tunnel that you will authenticate all or parts of later, you don't need RFC 4322. This was discussed many times, and always rejected as not good enough by the purists. Then the IETF created the BTNS Working Group which is spending huge amounts of time getting close to purity again. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
...whereas the key distribution systems we have aren't affected by eavesdropping unless the attacker has the ability to perform 2^128 or more operations, which he doesn't. Paul: Here you are assuming that key exchange has already taken place. But key exchange is the toughest part. That is where Quantum Key Distribution QKD comes in the picture. Once the keys are exchanged using QKD, you have to rely on conventional cryptography to do bulk encryption using symmetric crypto. Using Quantum Crypto to do bulk encryption doesn't make any sense. It is only useful in key distribution. saqib http://www.linkedin.com/in/encryption - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
At 10:44 AM -0700 6/22/07, Ali, Saqib wrote: ...whereas the key distribution systems we have aren't affected by eavesdropping unless the attacker has the ability to perform 2^128 or more operations, which he doesn't. Paul: Here you are assuming that key exchange has already taken place. No, I'm not. I am talking about protocols that do their own key exchange. IPsec. SSL/TLS. Kerberos. Etc. But key exchange is the toughest part. No, requiring that the two ends have a fixed connection which QKD works over is far tougher than using a proven protocol that works over any connection. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Fri, Jun 22, 2007 at 10:44:41AM -0700, Ali, Saqib wrote: Paul: Here you are assuming that key exchange has already taken place. But key exchange is the toughest part. That is where Quantum Key Distribution QKD comes in the picture. Once the keys are exchanged using QKD, you have to rely on conventional cryptography to do bulk encryption using symmetric crypto. QKD fails to come into the picture, because its key exchange is unauthenticated. I can do secure unauthenticated key exchange at zero cost using EECDH with no special quantum hardware. If the link is MITM-proof, I am done. Using Quantum Crypto to do bulk encryption doesn't make any sense. It is only useful in key distribution. What bulk-encryption system am I going to use that is usefully stronger than EECDH over secp384r1 (or tinfoil hat secp521r1). It is also not useful for key distribution. It remains (charitably) fiction. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
The wikipedia article has some information, but it could use some edits if you have new information. http://en.wikipedia.org/wiki/Opportunistic_encryption rearden On Fri, 22 Jun 2007 11:52:13 -0400 Sandy Harris [EMAIL PROTECTED] wrote: On 6/22/07, Eugen Leitl [EMAIL PROTECTED] wrote: So what's the state in ad hoc IPsec/VPN setup for any end points? The Linux FreeS/WAN project was working on opportunistic encryption. The general idea is that if you use keys in DNS to authenticate gateways and IPsec for secure tunnels then any two machines can communicate securely without their administrators needing to talk to each other or to set up specific pre-arranged tunnels. http://www.freeswan.org/freeswan_trees/freeswan- 2.00/doc/glossary.html#carpediem http://www.freeswan.org/freeswan_trees/freeswan- 2.00/doc/quickstart.html There is an RFC based on that work: ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt The FreeS/WAN project has ended. I do no know if the follow-on projects, openswan.org and strongswan.org, support OE. -- Sandy Harris Quanzhou, Fujian, China --- -- The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Click here to double your salary by becoming a medical transcriber http://tagline.hushmail.com/fc/Ioyw6h4eKoYjYstwQcEy9UxPRDQcZZyB8BukGw6meHWNNe4g9MQFew/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
At 10:44 -0700 2007/06/22, Ali, Saqib wrote: ...whereas the key distribution systems we have aren't affected by eavesdropping unless the attacker has the ability to perform 2^128 or more operations, which he doesn't. Paul: Here you are assuming that key exchange has already taken place. But key exchange is the toughest part. That is where Quantum Key Distribution QKD comes in the picture. Once the keys are exchanged using QKD, you have to rely on conventional cryptography to do bulk encryption using symmetric crypto. Using Quantum Crypto to do bulk encryption doesn't make any sense. It is only useful in key distribution. To be used in key distribution I have to have laid a private optical fiber between me and my correspondent. I could have paid a lot less for an armored truck to carry the key for me. (I know you can do QKD without the fiber these days, but how do you know that you agreed the key with the person you think you agreed it with? It's turtles all the way down.) Greg. saqib http://www.linkedin.com/in/encryption - 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: Quantum Cryptography
Ali, Saqib [EMAIL PROTECTED] writes: ...whereas the key distribution systems we have aren't affected by eavesdropping unless the attacker has the ability to perform 2^128 or more operations, which he doesn't. Paul: Here you are assuming that key exchange has already taken place. But key exchange is the toughest part. Key exchange is not the toughest part or even tough at all. Algorithms like Diffie-Hellman and variants on the theme work just fine. Authenticated protocols based on these algorithms are well understood and have been studied for defects for many years. The STS protocol and variants on it like the ones used in TLS are fine, and if you feel that they're not secure enough with the number of bits commonly used, you can crank up the dial for a lot less than the cost of one of these mind-bogglingly expensive boxes from MagiQ (not to mention the price of dedicated dark fiber between the endpoints.) That is where Quantum Key Distribution QKD comes in the picture. Once the keys are exchanged using QKD, you have to rely on conventional cryptography to do bulk encryption using symmetric crypto. I don't believe that any of the commercial units work that way, but if they do, my opinion of them has dropped even further, and it was already about as low as I thought was possible. Using QKD only for key exchange and using a conventional crypto system for the bulk of the data completely eliminates any conceivable benefits over more conventional techniques. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
