Re: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
Actually i would imagine that banks could have such a trusted position. They haven't done anything in the space but I am sure they will at some time. The problem isn't them holding the key but once it is in the hands of a third party it could easily be gotten to by the government (through a court order or under the US Patriot Act). Chuck Wegrzyn Ed Gerck wrote: Show me an enterprise/person who would like to have their private keys escrowed by a third-party, with all the liability/collusion/blackmail potential that goes with it, and I'll show you a client for VS. There are IMO many (and better) schemes when you want your private keys to be known by a TTP. Including PKI. Cheers, Ed Gerck - 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: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
- Original Message - From: Whyte, William [EMAIL PROTECTED] [...] But you don't have to contact the CA to get someone's certificate. A standard way is to send them an email saying can you send me a signed message? Yes, that works. When I want someone to send me confidential email, and that someone doesn't know much or anything about crypto, I usually just send an S/MIME signed email, and let his MUA (usually Outlook or Outlook Express) do the work of saving the certificate and all. This also ensures you have the right public key. I haven't studied the details of IBE, but I assume that (a) there may be multiple IBE-based CAs, with different parameters, and The way I see IBE being useful is as a corporate solution for encrypting messages. Inside a corporation everyone will use the same public parameter (which could probably come with the software installation). And in most corporate crypto solutions you want key escrow, which IBE gives you as well for free :) The benefit is that you don't need to deal with users public keys: you don't need to get them from some repository or ask the person to send it to you by email and stuff. So say that you are with your laptop away, and don't have the persons public key certificate, you can still send him/here email directly (without asking anyone to send you his/her public key). I admit the feature is of limted value however. (b) the identity that's used to encrypt will be not just a name, but a name and a date (to ensure that some revocation-like capability exists). In either case, you can't simply pick the email address and use it as the public key; you need to establish some additional information first. This seems to put us back in the same place as with standard PKI, usability-wise. (Or, rather, there may be a usability delta for IBE, but it's very small). In the Boneh-Franklin paper one suggestion is to use [EMAIL PROTECTED] || current-year which would make public keys good for one year (which sounds reasonable, especially within a corporation). Of course, the software will include the year when creating the public key, the users wouldn't need to do it explicitly. If you really want to be able to revoke public keys, you need more granularity and use something like [EMAIL PROTECTED] || current-date, and that does become anoying for the users (need to fetch your private key everyday). One interesting thing about IBE is that you can transform any such scheme into a Non-interactive forward-secret cryptosystem as Adam Back pointed out: http://www.cypherspace.org/~adam/nifs/ (his web server might be down, but you can look at the cached version on Google...). --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
At 18:31 07/07/2003 -0400, Tim Dierks wrote: ... So, it all boils down to a system that's not dissimilar to a traditional CA-based public key system. In order for you to participate, you go to the trusted third party, they verify that you own the e-mail address you're claiming to possess (with whatever level of verification they insist upon), and if you do, they generate your secret key for you and send it to you. You can now decrypt messages which other people encrypt with that public key. I don't think it's an interesting solution. I don't see any interesting application that's possible with this system which you couldn't do with existing public-key cryptography: for example, I could write a protocol software where you could request a public key ... Tim: wonderful concise summary and I couldn't agree more. Thanks for taking the time to explain so nicely why this kind of systems, while cute, are not really helping applied cryptography (IMHO). Best regards... Amir Herzberg http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
At 05:30 PM 7/8/2003, Nomen Nescio wrote: One difference is that with the identity-based crypto, once a sender has acquired the software and the CA's public key, he doesn't have to contact the CA to get anyone's certificate. He can encrypt to anyone without having to contact the CA, just based on the email address. Your proposed substitute doesn't allow for this. True, but how valuable is that, given that you can't send the actual message without contacting a server? I suppose one can construct theoretical scenarios where that's a benefit, but it seems to be a pretty narrow niche to me. but you don't need goofy new crypto to accomplish it. The Weil pairing hardly constitutes goofy new crypto. They are doing all kinds of cool stuff with pairings these days, including privacy-enhancing technology such as public keys with built-in forward secrecy. I retract the goofy. My point was that the market is incredibly reluctant to adopt new technology: if you can solve a problem with components known to the marketplace, you're much more likely to be successful than if you invent something new. This is above and beyond any reluctance to adopt new cryptographic technology based on concerns about security. Even if the Weil pairing is known to be 100% secure and tested, any new solution has to, as a practical matter, leap a huge hurdle to overcome available, well known alternatives. I've spent years attempting to get the market to accept alternative security solutions, and I can testify to how high that hurdle is. In my opinion, identity-based cryptography has insufficient upside to overcome that hurdle, especially given that it is not without its downsides (escrowed private keys, no protection against key compromise). - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
One difference is that with the identity-based crypto, once a sender has acquired the software and the CA's public key, he doesn't have to contact the CA to get anyone's certificate. He can encrypt to anyone without having to contact the CA, just based on the email address. Your proposed substitute doesn't allow for this. But you don't have to contact the CA to get someone's certificate. A standard way is to send them an email saying can you send me a signed message? This also ensures you have the right public key. I haven't studied the details of IBE, but I assume that (a) there may be multiple IBE-based CAs, with different parameters, and (b) the identity that's used to encrypt will be not just a name, but a name and a date (to ensure that some revocation-like capability exists). In either case, you can't simply pick the email address and use it as the public key; you need to establish some additional information first. This seems to put us back in the same place as with standard PKI, usability-wise. (Or, rather, there may be a usability delta for IBE, but it's very small). When you add to this the fact that the server knows your decryption key... I really don't see why this is worth getting excited about commercially, or even from an engineering perspective. It's cool maths, though. Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
A Simpler, More Personal Key to Protect Online Messages By JOHN MARKOFF The New York Times I wrote this for another list I'm on: This system is based on an identity-based cryptography scheme developed by Dan Boneh with Matt Franklin. You can find a link to his paper Identity based encryption from the Weil pairing on Dr. Boneh's website, http://crypto.stanford.edu/~dabo/pubs.html . The system allows any predetermined public value (e.g., an e-mail address) to be a public key. To encrypt a message, you do a mathematical operation as follows: EncM = E(M, pubKey, p) Where: EncM is the encrypted message E is the encryption operation M is the message pubKey is the public key (e-mail address) p is a set of public domain parameters The parameters p are a set of values which any subset of people can use to communicate with each other, but which must be predetermined by a trusted party and shared with all communicants. When the trusted third party creates the public domain parameters, there is a matched set of secret domain parameters (call them sp) which allow the trusted party to determine the matching secret key for any public key. Namely, in this system, for every pubKey there is a matching secKey which can be used to decrypt an encrypted message. The secret domain parameters are needed to be able to calculate secKey from pubKey: secKey = KD(pubKey, sp) Where KD is the key derivation algorithm. So, it all boils down to a system that's not dissimilar to a traditional CA-based public key system. In order for you to participate, you go to the trusted third party, they verify that you own the e-mail address you're claiming to possess (with whatever level of verification they insist upon), and if you do, they generate your secret key for you and send it to you. You can now decrypt messages which other people encrypt with that public key. I don't think it's an interesting solution. I don't see any interesting application that's possible with this system which you couldn't do with existing public-key cryptography: for example, I could write a protocol software where you could request a public key from a server for any e-mail address; if the user didn't already have an enrolled key, my trusted server would generate one and enroll it on their behalf. When they got an encrypted message, they could contact me, authenticate themselves, and I'd send them their secret key. The functionality ends up being pretty much the same, but you don't need goofy new crypto to accomplish it. Furthermore, no-one's bothered to deploy the system I describe (although it's obvious) which implies that market demand for such a system hasn't been held back by the fact that no one had figured out the math yet. All of this, on top of the fact that the private key, is, in essence, escrowed by the trusted third party, causes me to believe that this system doesn't fill an important unmet need. - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
