Re: Fwd: [IP] A Simpler, More Personal Key to Protect OnlineMessages
Tim Dierks wrote: ... 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. I'm not sure that's the case! There are some markets out there where there are some contradictory rules. By this I mean, all messages must be private, and all messages must be readable. Now, the challenges that these markets must meet point them in the direction of having a central server doing key escrow. But, the central server is not allowed to escrow the messages or be able to read the messages. A further challenge is that these markets are full off leakages, and so what is needed is a way of taking the crypto capability away from users. This solution seems to do this latter part, in that it achieves the contradictory requirements of making every message unreadable, but crackable, and it - in theory - does not give users any ability to do their own crypto and thus bypass the system. A (purely hypothetical) example, to clarify what this market looks like: Imagine the NSA had to outsource its encrypted comms. They want all messages to be secret because .. that's kind of their mission. But, they are worried about moles in the organisation, so they want to be able to open up the whole shebang somehow and go trolling for data. So how do we rationalise all this? Simple - the people who use the system are not the people who buy the system. The market for this system is not users but corporates with special needs. In fact if we look at the website, it's oriented to selling into 4 markets: corporates, financial, health, and government, If we ignore the first as a catchall phrase, the remaining three all have special needs when it comes to privacy. And those needs aren't so much to do with the user as with the organisation. It was for these markets that companies like PGP Inc put in their fabled alternate decryption key, and companies like Hushmail sell corporate packages. -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 05:31:45PM -0700, Eric Rescorla wrote: All else being equal, a protocol which provides more security is better than a protocol which provides less. Now, all things aren't equal, but if you can offer substantially more security with only a modest increase in code complexity, that's generally a good thing. Where hard tradeoffs have to be made is when the users are inconvenienced. A little additional programming doesn't seem like a high cost at all. I agree with this. I don't find this sort of sure, it's nowhere near as secure as secure as SSL, but it takes up a little less space argument very compelling at all. To my mind, one of the things that's been unstated in this thread is that Tom should have looked at the protections involved in the SSL streams (all the anti-replay, message integrity etc), but concentrated on stripping down the unnecessary overhead of, for example, ciphersuite negotiation and other bits of protocol which are the plumbing part of SSL rather than the cryptographic parts. As someone who has read parts of the OpenSSL 0.9.7 source, I'm sure that it is possible to implement SSL with less obscurity layers than the general purpose library. If you can skip out the cipher and protocol parameter negotation then you can probably reduce the complexity down to a truly manageable level (rather than a possible nasty in the state machine (he says, thinking back to the vulnerability in OpenSSL a year ago)) and hopefully without changing the security of the stream protocol significantly. Of course that doesn't help if what you really need is a general-purpose secure socket transport ;-) MBM -- Matthew Byng-Maddick [EMAIL PROTECTED] http://colondot.net/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: [IP] A Simpler, More Personal Key to Protect OnlineMessages
From my very practical position ( I was the CTO of Authentica and responsible for their email and web technology) there are truths to the email from Ian. Though I will also state that their is a very real segment of the marketplace which does require a user to have secure messaging while the corporation might not. Chuck Wegrzyn Ian Grigg wrote: Tim Dierks wrote: ... 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. I'm not sure that's the case! There are some markets out there where there are some contradictory rules. By this I mean, all messages must be private, and all messages must be readable. Now, the challenges that these markets must meet point them in the direction of having a central server doing key escrow. But, the central server is not allowed to escrow the messages or be able to read the messages. A further challenge is that these markets are full off leakages, and so what is needed is a way of taking the crypto capability away from users. This solution seems to do this latter part, in that it achieves the contradictory requirements of making every message unreadable, but crackable, and it - in theory - does not give users any ability to do their own crypto and thus bypass the system. A (purely hypothetical) example, to clarify what this market looks like: Imagine the NSA had to outsource its encrypted comms. They want all messages to be secret because .. that's kind of their mission. But, they are worried about moles in the organisation, so they want to be able to open up the whole shebang somehow and go trolling for data. So how do we rationalise all this? Simple - the people who use the system are not the people who buy the system. The market for this system is not users but corporates with special needs. In fact if we look at the website, it's oriented to selling into 4 markets: corporates, financial, health, and government, If we ignore the first as a catchall phrase, the remaining three all have special needs when it comes to privacy. And those needs aren't so much to do with the user as with the organisation. It was for these markets that companies like PGP Inc put in their fabled alternate decryption key, and companies like Hushmail sell corporate packages. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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: Voltage - Identity Based Encryption.
On Mon, 7 Jul 2003, Hack Hawk wrote: So what they're saying is that your PRIVATE key is stored on a server somewhere on the Internet?!?! No, this (like Kerberos) works best in a federated model. Each organization (or group of organizations that trust a common third party and have mechanisms to authenticate their users to said party) runs a key server. The recipient's address together with the organization-wide public key of the recipient's server (s.P) allow the sender to unilaterally construct a session key that is only recoverable by recipient's private key which is derived from the recipient's server secret and the recipient's identity. The recipient needs to (at least once) authenticate to *his* server and get his private key. The server secret s (like a KDC master key in Kerberos) yields *everyone's* private key in the organization in question. Unlike a KDC the database consists only of a single secret! If a user's key is compromised, the user needs to change identities (email adddreses). If a server key is compromised, ... This obviates the need for key exchange between individual users, but creates a need for a TTP in each participating organization or consortium. I look at this as a Kerberos alternative with a public/private master key. Creating a session key does not involve any calls to the KDC because the KDC public keys are published. Interactive user principals can avoid storing their keys in persistent storage, by authenticating each time (the mail client starts), disconnected users or server applications store secrets in access controlled storage (analogous to keytabs). In an AD environment the authentication to the new key server can use the real Kerberos... Unlike the real Kerberos this does not require (n^2)/2 keys, but it does require (n^2)/2 key exchanges of n keys, otherwise one gets back to Verisign style models for server key signing. Key management does not ever go away! How does one secure the key management? (Bilaterial diplomatic cases chained to wrists work, but are difficult on an Internet scale)... If all server keys are held in write-only tamper-proof hardware, perhaps server key revocation will be rare and key exchanges might be less frequent... As on online protocol, it resembles Kerberos even more, but perhaps works better accross organizational boundaries. Each organization periodically obtains via some secure channel the public keys of their business partners. These are leveraged to create secure channels between users. The channels are not server mediated so unlike a VPN or SMTP+TLS, the crypto is end-to-end with the servers at each site holding a secret that can compromise every user. I doubt Voltage.com will be able to sell everyone on a single server for the whole Internet so the bilateral key management problem does not go away, it just gets factored into clumps... Please correct my impression if I got this completely wrong... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
replay integrity
Eric Rescorla wrote: You keep harping on certs, but that's fundamentally not relevant to the point I was trying to make, OK! which is whether or not one provides proper message integrity and anti-replay. As far as I'm concerned, there are almost no situations in which not providing those services is appropriate. That kind of infrastructure is already built into SSL and shouldn't be reinvented. Welcome to the applications world! Integrity: Financial protocols that use crypto (as opposed to ones abused by crypto) generally include signed messages. The signature provides for its own integrity, as well as a few other things. Replay: One of the commonest problems in HTTPS sites is replay failure. The solution is well known out in the real world - you have to have replay prevention at the higher layers. (Credit card processors have replay prevention too!) So, some protocols don't need replay prevention from lower layers because they have sufficient checks built in. This would apply to any protocols that have financial significance; in general, no protocol should be without its own unique Ids. I wouldn't say that this is a good reason to take these features out of SSL. But assuming they are needed is a cautious assumption, and assuming that SSL meets the needs for replay integrity makes even less sense when we are dealing with a serious top-to-bottom security model. It's simply the case that a serious financial protocol would have to have its own replay integrity, because its threat model and failure model is so much broader than SSL's. For example, a serious payments scenario works across end-to- end, and assumes that nodes on both end-points can be compromised and/or faulty. And, it's not only just faults, many higher layers actively replay as part of the protocol. SSL just doesn't address the security needs of protocols as well as all that. Where I've seen it used, the core need for it is privacy of the data stream, not anything else. (As a sort of oxymoron, a payments or similar protocol that didn't have its own replay integrity would not work. Ideally, a good test of a payments protocol is to see if it would work over unprotected UDP or email. Some do and some don't.) -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: replay integrity
I wouldn't say that this is a good reason to take these features out of SSL. But assuming they are needed is a cautious assumption, and assuming that SSL meets the needs for replay integrity makes even less sense when we are dealing with a serious top-to-bottom security model. [ ... ] SSL just doesn't address the security needs of protocols as well as all that. Where I've seen it used, the core need for it is privacy of the data stream, not anything else. Maybe so, but if you don't have integrity checking, so that an attacker can inject packets into the stream, this can often compromise privacy too. For example, consider Serge Vaudenay's CBC padding attack. Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: replay integrity
tom st denis [EMAIL PROTECTED] writes: --- Eric Rescorla [EMAIL PROTECTED] wrote: This is all fine, but irrelevant to my point, which is that if you're designing a channel security protocol it should provide channel level integrity and anti-replay unless there's some really good reason not to. For the love of god the horse is dead. Let it be! I've pulled the code [and the rest of the site]. I admitted you were right, I admited it had unintentional flaws. What more do you want? Tom, I'm sorry you're taking this personally, since it's not really about you. I take Ian to be making a generic argument that there's not a need for these features in a channel security protocol. I've certainly hear this argument before and I think it's worth discussing--even though I think he's wrong. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: replay integrity
Integrity: Financial protocols that use crypto (as opposed to ones abused by crypto) generally include signed messages. The signature provides for its own integrity, as well as a few other things. I don't believe that is enough. Take for example the SSL 2.0 ciphersuite rollback vulnerability or the SSL 3.0 key-exchange algorithm vulnerability . Any kind of rollback attack is serious, and won't be protected by signatures in the bulk data (and those signature might be weakened by forcing a rollback to a possible weaker version/implementation). Replay: One of the commonest problems in HTTPS sites is replay failure. The solution is well known out in the real world - you have to have replay prevention at the higher layers. (Credit card processors have replay prevention too!) So, some protocols don't need replay prevention from lower layers because they have sufficient checks built in. This would apply to any protocols that have financial significance; in general, no protocol should be without its own unique Ids. So maybe I can't replay a complete financial transaction, because at some high layer there is replay prevention, what about replaying some init protocol request? Is that not annoying? Would a bank not care that their ATMs are not working for a day because someone is executing a DoS attack on the lower layers of the protocols of their system? I think not, you need replay protection on both levels. How can a secure socket be dubbed secure if it doesn't protect against these basic attacks? To quote from Wagner and Schneier`s paper, Analysis of the SSL 3.0 protocol: Replay attacks are a legitimate concern, and as they are so easy to protect against, it would be irresponsible to fail to address these threats. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Grey-World
An excellent site for those interested in tunneling, covert channels, network related steganographic methods developments. http://gray-world.net/ There is no protection or safety in anticipatory servility. Craig Spencer - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
