Re: public-key: the wrong model for email?
On Thu, Sep 16, 2004 at 06:12:48PM +0100, Ian Grigg wrote: | Adam Shostack wrote: | Given our failure to deploy PKC in any meaningful way*, I think that | systems like Voltage, and the new PGP Universal are great. | | I think the consensus from debate back last year on | this group when Voltage first surfaced was that it | didn't do anything that couldn't be done with PGP, | and added more risks to boot. So, yet another biz | idea with some hand wavey crypto, which is great if | it works, but it's not necessarily security. Sure, I like the system even if it breaks, because it focuses on ease of use. I didn't say I thought it secure. | * I don't see Verisign's web server tax as meaningful; they accept no | liability, and numerous companies foist you off to unrelted domains. | We could get roughly the same security level from fully opportunistic | or memory-oportunistic models. | | Yes, or worse; it turns out that Verisign may very | well be the threat as well as the solution. As I | wrote here: | | http://www.financialcryptography.com/mt/archives/000206.html | | Verisign are in the eavesdropping business, which | not only calls into doubt their own certs, but also | all other CAs, and the notion of a trusted third | party as a workable concept. Yes. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: public-key: the wrong model for email?
At 10:19 PM 9/15/2004, Ed Gerck wrote: Yes, PKC provides a workable solution for key distribution... when you look at servers. For email, the PKC solution is not workable (hasn't been) and gives a false impression of security. For example, the sender has no way of knowing if the recipient's key is weak (in spite of its length) or has some key-access feature. Nonetheless, the sender has to use that key. I don't understand the threat model here. The usual models are - Key too short - Obvious to the sender - Recipient's machine is compromised - Not obvious to sender, but not fixable by email program - Recipient is stupid and careless - Often obvious to sender, but not fixable by email program - Recipient's Public Key generator system generates weak keys - Hard for sender to detect and work around - Usually requires extra work by recipient to obtain compromised software, unless mandated by Corporate IT Droids - Recipient can reduce risk by using open source software - Recipient's Public Key generator mails copy of private key to keyserver.kgbvax.gov - Indistinguishable from previous case - Recipient's Client Software mails copy of session key to ashcroft.kgbvax.gop - Indistinguishable from previous case - Recipient's Email Client forwards incoming mail message plaintext disguised as bouncegrams or viruses. - Indistinguishable from previous case. - Recipient's Secret Key is recipient's dog's name spelled backwards, written on yellow sticky note pasted next to open window, under the big mirror with a good view of recipient's keyboard and screen. - Not a software problem - Recipient's Computer Disk automatically backed up to optical storage at night - No sense subpoenaing cyphertext when you can subpoena plaintext. You're focusing on a relatively niche threat model, unless there's some operational aspect here I'm missing. If you wanted to do something fancy, you could insist that the recipient send the sender a Diffie-Hellmann Half-Key, which you use to generate a session key that you use for message encryption, and transmit your DH half-key along with the encrypted message for the sender to decrypt. It's still subject to most of the same threats as the RSA-like public-key model, though maybe it's a bit easier to detect weak Diffie-Hellmann keys. However, unless you want to force the recipient to change their client interface, the easier place to implement something is in their SMTP client, and the obvious way to do that is some variant on SSL-SMTP. If you _still_ want more control, set up a web server, and instead of sending your actual secret message, send Encrypt ( Key=Alice, Message= - BEGIN PGP SIGNED MESSAGE Alice - I've sent you an encrypted message at https://bob.example.net/cookie123456.PGP This URL will self-destruct in 5 business days. - Bob - END PGP SIGNED MESSAGE ) However, if Alice was using a compromised email client, she could just as easily be using a compromised browser. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: public-key: the wrong model for email?
Adam Shostack wrote: On Thu, Sep 16, 2004 at 12:05:57PM -0700, Ed Gerck wrote: | Adam Shostack wrote: | | I think the consensus from debate back last year on | this group when Voltage first surfaced was that it | didn't do anything that couldn't be done with PGP, | and added more risks to boot. | | Voltage actually does. It allows secure communication | without pre-registering the recipient. Generate a key for [EMAIL PROTECTED] encrypt mail to Bob to that key. When Bob shows up, decrypt and send over ssl. How do you know when the right Bob shows up? And...why encrypt? The email never left your station. Your method is equivalent to: send anything to Bob at [EMAIL PROTECTED]. When Bob shows up pray he is the right one and send email over ssl. You also have to run an ssl server (or trust Bob's server key). With Voltage, you encrypt the email to [EMAIL PROTECTED] and send it. The sender's work is done[*]. Yes, the other problems still exist with Voltage. Cheers, Ed Gerck [*] The recipient can decrypt the Voltage email only IF both the sender and recipient can refer to the same key generation parameters for the recipient. This is a problem that I have not seen Voltage discuss. Users in different or competing administration boundaries will not be able to communicate with each other in general. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Symantec to acquire @Stake
http://www.siliconvalley.com/mld/siliconvalley/9682511.htm?template=contentModules/printstory.jsp The San Jose Mercury News Posted on Thu, Sep. 16, 2004 Symantec to acquire digital security company CUPERTINO, Calif. (AP) - Symantec Corp. said Thursday it is acquiring digital security consulting firm stake Inc. Financial details were not disclosed. The deal is expected to close next month. Cupertino, Calif.-based Symantec is one of the world's biggest information security companies, selling consulting services and software such as the Norton AntiVirus program. The company does business with individuals and corporations in more than 35 countries. Cambridge, Mass.-based stake sells consulting services and computer programs to protect networks from hackers and other security risks. Businesses that have purchased the company's SmartRisk and other products include six of the world's top 10 financial institutions and four of the world's 10 top independent software companies. ``Our customers are looking to us for a broad range of security expertise,'' said Gail Hamilton, a Symantec executive vice president. ``By joining forces with the leader in application security consulting, we expand the capacity and capabilities of our consulting organization.'' Symantec shares rose 31 cents to close at $51.32 Thursday on the Nasdaq Stock Market. -- On the Net: Symantec: http://www.symantec.com stake: http://www.atstake.com/ -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: public-key: the wrong model for email?
At 05:35 PM 9/16/2004, Adam Shostack wrote: Generate a key for [EMAIL PROTECTED] encrypt mail to Bob to that key. When Bob shows up, decrypt and send over ssl. note there is still the issue of knowing it is bob ... whether before the transmission or after the transmission and, in fact, the transmission itself is somewhat arbitrary. in the physical world ... the base point is that the sender pays to physically transmit something. there is threat model of taking physical possession of whatever is being transmitted. they then pay extra for countermeasures wrong person taking physical possession. they also pay extra for extra care in delivery to the correct person. the current electronic world ... the base point is that the sender doesn't actually pay per transmission. with encryption, the threat model is changed to possession of the unencrypted information. encryption (shared-secret or digital signatures) is also used to help with the issue of delivery to the correct person (although the convention is converted to the correct person decrypts the data). so what is the difference between the sender setting up facility so that when bob shows up bob gets a decrypted version and say sending a version to some trusted 3rd party that is encrypted with the 3rd party's key ... and direction to only let bob have it when bob shows up. how does the 3rd party know its bob ... any better than the originating sender? note also in standard ssl ... the recipient generates a random symmetric key and sends it to the server, encrypted with the server's public key. there is nothing about how the server knows that the bob making the contact ... and the bob that is suppose to receive the information is the same entity. so the 3rd party keeps the pre-transmitted encrypted stuff with directions to only give it to any entity that shows the magic something (the movie stuff about tearing a bill in half and the person needs to have the appropriate torn half). the 3rd party holds it until bob contacts the sender and gets the magic something ... which they they can give to the 3rd party. given the nature of electronic transmission ... is that really substantially different than the sender waiting until bob contacts them before doing the original transmission. if it is purely electronic world ... how does the sender get the necessary information to the correct bob ... so that the correct bob can give the stuff to the 3rd party ... to proove that they are the correct bob. so possibly the only distinction ... is that the email communication between bob and the sender is non-real-time ... and the SSL communication is considered possibly real-time so the scenario isn't actually the information being transmitted between the sender and bob that is the issue ... it is possibly the mechanics of real-time vis-a-vis non-realtime? so the sender at some point has to trust bob's authentication information (whether directly and/or outsourced to 3rd party) ... say digital signature public key and may or may not trust that same key for encryption. common pgp flow ... which effectively is the same as ssl same process steps ... but possibly not in real time. sender looks up in some directory the contact information for bob, this directory is trusted to map the contact process for bob to bob the directory may or may not also provide some authentication information for bob. if the sender doesn't have authentication information for bob ... they send message to bob requesting authentication information. when they get that back, they vet the authentication information before using it to make sure it is actually for bob. so now they have a process which has some assurance of contacting bob and some assurance that bob can be authenticated. this is pretty much true whether the actual sender is responsible for the steps or has been outsourced to some 3rd party. now the issue is wether or not the authentication information is also trusted to securely protect the classified information during transmission (aka public key). possible scenario if sender requires different encryption keys from authentication information: 1) sender sends message to bob saying classifed document is waiting. bob generates secret key, digitally signs it, encrypts it with the senders public key and returns it to the sender. this could be all email exchange ... or possibly combination of email and ssl it could also be directly with the sender or a 3rd party agent on the sender's behalf. 2) the sender decrypts bob's message, validates the digital signature, encrypts the classified information with bob's secret key and sends the information to bob. the sender's process can be email or ssl ... and can either directly be the sender ... or a 3rd party acting on the sender's behalf. for efficiency purposes the acquisition of bob's authentication information and possible encryption key
Re: public-key: the wrong model for email?
On Thu, Sep 16, 2004 at 04:57:39PM -0700, Bill Stewart wrote: At 10:19 PM 9/15/2004, Ed Gerck wrote: Yes, PKC provides a workable solution for key distribution... when you look at servers. For email, the PKC solution is not workable (hasn't been) and gives a false impression of security. For example, the sender has no way of knowing if the recipient's key is weak (in spite of its length) or has some key-access feature. Nonetheless, the sender has to use that key. I don't understand the threat model here. That seems to be the actual problem. If you want real security, you need a vault, guards, cryptographers, and do the crypto in the vault. I use GnuPG so my e-mail is in an envelope rather than on a postcard. If the fedz want to read it they bring guns, slammers, and rubber hoses anyway. Perhaps it is time to define an e-mail definition of crypto to keep the postman from reading the postcards. That should be easy enough to implement for the average user and provide some degree of privacy for their mail. Call it envelopes rather than crypto. Real security requires more than a Windoz program. -- [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: public-key: the wrong model for email?
lrk wrote: Perhaps it is time to define an e-mail definition of crypto to keep the postman from reading the postcards. That should be easy enough to implement for the average user and provide some degree of privacy for their mail. Call it envelopes rather than crypto. Real security requires more than a Windoz program. Oh, that's really easy. Each mailer (MUA) should (on install) generate a self-signed cert. Stick the fingerprint in the headers of every mail going out. An MUA that sees the fingerpring in an incoming mail can send a request email to acquire the full key. Or stick the entire cert in there, it's not as if anyone would care. Then each MUA can start encrypting to that key opportunistically. Lots of variations. But the key thing is that the MUA should simply generate the key, sign it, and send it out on demand, or more freuqently. There's really no reason why this can't all be automated. After all, the existing email system is automated, and trusted well enough to deliver email, so why can't it deliver self-signed certs? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Openswan dev] [Announce] Openswan 2.2.0 released
--- begin forwarded text Date: Fri, 17 Sep 2004 17:48:25 +0200 (MET DST) From: Paul Wouters [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Openswan dev] [Announce] Openswan 2.2.0 released List-Id: Openswan developer mailinglist dev.openswan.org List-Archive: http://lists.openswan.org/pipermail/dev List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://lists.openswan.org/mailman/listinfo/dev, mailto:[EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Xelerance is proud to release Openswan 2.2.0 It is available at the usual locations: http://www.openswan.org/code/openswan-2.2.0.tar.gz ftp://ftp.openswan.org/openswan/openswan-2.2.0.tar.gz A seperate NAT-traversal patch and seperate KLIPS patch are available as well. RPMS have been released for RedHat-9, Fedora Core 2 and 3-test1, RHEL3 and Suse 9.1. (RedHat-9 still requires KLIPS support in the kernel). All released files have been signed with the [EMAIL PROTECTED] GPG key available from the keyservers. The following are the most important changes: * Added RFC 3706 DPD support (see README.DPD) * Added AES from JuanJo's ALG patches * Fixes for /proc filesystem issues that started to appear in 2.4.25 * Merge X.509 1.5.4 + latest security fixes (CAN-2004-0590) * Updated .spec for building RPMS compatible with Kernel 2.6 * Merge X.509 security fixes from 1.6.3 * Fixes for NAT-T on 2.6 pulled up from 2.1.x (Herbert Xu) * Fixes for SA Selectors on 2.6 pulled up from 2.1.x (Herbert Xu) Bugs can be reported via http://bugs.openswan.org/ or via one of the mailing lists at http://lists.openswan.org/ Paul ___ Announce mailing list [EMAIL PROTECTED] http://lists.openswan.org/mailman/listinfo/announce ___ Dev mailing list [EMAIL PROTECTED] http://lists.openswan.org/mailman/listinfo/dev --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: public-key: the wrong model for email?
Bill Stewart wrote: At 10:19 PM 9/15/2004, Ed Gerck wrote: Yes, PKC provides a workable solution for key distribution... when you look at servers. For email, the PKC solution is not workable (hasn't been) and gives a false impression of security. For example, the sender has no way of knowing if the recipient's key is weak (in spite of its length) or has some key-access feature. Nonetheless, the sender has to use that key. I don't understand the threat model here. The usual models are ... Good list, even though missing some points that are important here, mentioned below. The disclosure threat is that the message may be disclosed AFTER it is decrypted (this may happen even without the recipient being at fault). I am NOT talking about the disclosure threat. Except for the disclosure threat, the threat model includes anything that is not under control or cannot be directly verified by the sender. The obvious strategy for the sender is to trust the least possible (ideally, nothing) regarding message security. Public-key encryption for email makes this difficult from the start. With all the public-key fancy foot work (eg, CA certs, CRL, OCSP, etc.), the sender still has to trust the public-key generated by the recipient regarding its basic property to encrypt messages that can only be decrypted by the recipient when the message arrives. Yes, the sender can do a challenge-response using that key and confirm that the recipient has the private-key. But what the sender does not have, and cannot have, is any assurance that his messages are only decryptable by the recipient. The sender has no way of knowing if the recipient's public-key is weak (in spite of its great length), or has some key-access feature, or bug, or has been revoked in the mean time [1]. Trusting the recipient helps but the recipient may not even know it (in spite of the recipient's best efforts). This problem also affects SSH and anything that uses public-key crypto, including smart-card generated keys. For email, however, it can break message security in spite of the sender's and recipient's best efforts. Since the sender is the party who bears most, if not all, the risk, my question was whether email security could benefit by using a different model. Public-key crypto could still be used, but possibly not as it is today. Again, the problem is both technical and business-wise. If you _still_ want more control, set up a web server, and instead of sending your actual secret message, send Encrypt ( Key=Alice, Message= - BEGIN PGP SIGNED MESSAGE Alice - I've sent you an encrypted message at https://bob.example.net/cookie123456.PGP This URL will self-destruct in 5 business days. - Bob - END PGP SIGNED MESSAGE ) The attacker could read the first message and download the second message. It could make it detectable, though (but not necessarily traceable). Cheers, Ed Gerck [1] The security fault happens when you (in spite of all your best efforts) send an email message using a public-key that is revoked (eg, because the private-key was compromised) at the time the message is received, due to various delays such as in message transport, certificate revocation, and compromise discovery. You simply have no way of knowing, even if the key was not listed in a CRL at the very second you sent the message, whether the key has not been compromised at the time the message is received. It gets worse. If the private-key is compromised any time after the message is sent, the message can be decrypted from a cache copy somewhere -- even if the recipient keeps the decrypted copy safe. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
