Re: crypto question
At 01:04 PM 3/21/02 -0500, Nelson Minar wrote: Question. Is it possible to have code that contains a private encryption key safely? As a practical matter, yes and no. Practically no, because any way you hide the encryption key could be reverse engineered. Practically yes, because if you work at it you can make the key hard enough to reverse engineer that it is sufficient for your threat model. This problem is the same problem as copy protection, digital rights management, or protecting mobile agents from the computers they run on. They all boil down to the same challenge; you want to put some data on a computer you don't control but then restrict what can be done with that data. The fundamental issue is: who benefits from keeping the secret secret? If the holder of the bankcard (or whatever) is liable for abuse due to cracking, you are in a much better position than if the bank loses when a cracker cracks the card in his possession. This of course does not help when an adversary *steals* access to the secret in the bankcard. It only helps when the holder of the secret has an interest in keeping the secret. One gathers from this discussion that the content-creator is worried about content-users cracking their system; that is in general hopeless, modulo the cost factors. (And remembering what Schneier wrote about all it takes is one cracker + the internet, if a crack tool is readily copied.) dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
An attack on the 'Trusted Traveler' Pass
Some day in the future, maybe a year from now, you may have a trusted traveler card. Congress wants it, the airlines need it and security experts endorse it. The benefits appear clear. With a tool to separate the wheat from the So does an attack. Befriend someone with such a card, give her a gift with well hidden, unscented plastique and a barometric detonator. After some time she takes her planned flight and gets only a cursory exam. She neglects to mention the gift she's carrying (they don't even ask the 2 security questions reliably, any more, anyway). It worked over Lockerbie, it'll work again. The Lockerbie carrier had the equivalent of a trusted traveller card --she was a white woman. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
At 01:59 PM 1/14/02 -0800, Eric Rescorla wrote: Saying that SSL without certificates is fine as long as you don't have active attacks is kind of like saying that leaving your front door open is fine as long as noone tries to break in. No, its more. SSL sans certs is like using envelopes to write to Dear Abby. You have no authentication on who Dear Abby really is but your communications are private. Since the entity who claims to be Dear Abby also gives a communications address, writing to Dear Abby at that address is sufficient. (Modulo MIM attacks) [Moderator's note: Except that's precisely the point: Modulo MIM attacks is like saying we're all immortal, modulo death. The question isn't some sort of mystification of identity -- it is being able to know that you're talking to the same Dear Abby your friends have talked to and that you talked to last week. Now that MIM attacks have been automated they don't even need sophistication to conduct. --Perry] When you call a phone number listed with an advert, and give them your credit card number, you have less confidentiality (you're speaking plaintext), but its the same model. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
[The question isn't some sort of mystification of identity -- it is being able to know that you're talking to the same Dear Abby your friends have talked to and that you talked to last week. Here you're talking about reputation of nyms, which doesn't require third parties or certs, just well-kept secret keys of a PK pair. If the remote entity keeps using the same PK keys, you can reasonably update reputation based on that alone. (They're essentially signing their behaviors.) [Moderator's note: I fully agree. I was disputing only the notion that unauthenticated connections were sufficient. Authentication does not require certificates or third parties -- see the way SSH handles keys for example. --Perry] Now that MIM attacks have been automated they don't even need sophistication to conduct. --Perry] Since a signed cert is useful for recovering ZERO dollars from the signer, if you've been defrauded by some entity, the end result is the same if a MIM defrauds you. A *trusted* signer would solve the confidentiality loss problem but not the financial liability problem. But given that signers will sign *anything* (and why not, they have no financial liability and little useful reputation to lose) this is a small difference. dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
At 10:49 AM 1/12/02 -0800, Carl Ellison wrote: If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? Check the certificate. More demos: You can create your own cert with TinySSL, a lightweight ( 100Kbyte) server for Wintel, http://www.ritlabs.com/tinyweb/tinyssl.html and amuse your friends if they bother to read the info there. Using trademarks (RSA, Verisign, etc.) in the fields would escape most. Or, as the TinySSL docs advise, you can get a free cert from Thawte --which *in fact* certifies only that you can receive email at the address you gave them. As others have written, great for enabling SSL's confidentiality, nothing else. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
