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 might be collapsed into single round trip. sender (or 3rd party on sender's behalf) send bob a message that they need both bob's authentication information .... as well as a digitally signed, randomly generated secret key ... which is encrypted with the supplied public key. the sender/3rd party then has to vet bob's authentication information .... before using the randomly generated secret key. again, the exchange could be purely non-real-time email .... or combination of email and real-time ssl.

sort of practical issues:

given that the electronic paradigm have enuf differences from the physical world sending model (i.e. sender doesn't pay in the base case) .... can sender's be induced to pay 3rd party to outsource some of the operations?

given that the there are some number of other vulnerabilities and exploits in the overall infrastructure .... is the treat model specifically to trusting bob's public key for both authentication and confidential transmission .... sufficient to impose the extra processes (and/or convince sender's that they need to pay extra money for outsourcing to 3rd parties).

since the paradigm issue of securely transmitted has changed from secure physical movement to safe encryption .... a 3rd party may only have to provide a business of assuring recipients' public keys for "safe" transmission (as opposed to actually doing the transmission). everybody gets to generate their own public/private key pair for authentication. the same key pair is not used for both authentication and encryption. people may also generate their own encryption key pair.

senders either trust a recipient's encryption key pair ... or they don't. if the sender doesn't trust a recipient's encryption key pair .... they ask for a encryption public key that has been issued by a trusted 3rd party ... and for which the 3rd party is willing to attest to. there is an issue of how the issued private key has gotten to the recipient ... but that isn't a whole lot of difference than the process of a recipient exchanging a real secret key for transmission. there is an issue of whether or not the recipient has continued to protect the encryption private key .... but that isn't a whole lot difference than whether or not the recipient has the facility to protect the unencrypted classified document (once they receive it).

the physical world has the sender outsourcing and paying for the actual secure physical movement .... and some assurance that it only goes to the intended recipient. translated to the electronic world ... the paradigm has been changed to the use of encryption to make sure wrong people don't have the unencrypted version ... and various kinds of authentication processes. so the critical processes has changed not from the actual movement of the data ... but the encryption process "gatekeepers" .... aka the integrity and management of keys used for authentication and decryption. so rather than focus on the actual electronic transmission processes .... focus on the issues related to the keys.

Anne & Lynn Wheeler

--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to