Ben Laurie wrote:

Ed Gerck wrote:
If the recipient cannot in good faith detect a key-access ware, or a
GAK-ware, or a Trojan, or a bug, why would a complete background
check of the recipient help?

Let's assume for a moment that a solution exists that satisfies your requirements. Since the recipient _must_ be able to read the document in the end, and is assumed to be incapable of securing their software, then the document is still available to third parties without the consent of the sender, is it not?

The recipient was not assumed to be entirely incapable of securing his software. The recipient can be trusted to do a number of things that are basic, for example, to operate an email software. In fact, we can even assume a pretty sophisticated recipient, trained to use all the security email software systems commercially available. Still, the recipient will be incapable of verifying whether his RSA private-key is weak or not. Thus, even fully unwillingly and under best efforts, the recipient can put the sender's message security at risk when using that recipient's RSA public- key.

It seems to me that fixing the PK "problem" would in no way improve the senders situation given that threat model.

The sender's situation can be improved mostly when the sender trusts the least possible (ideally, nothing) regarding message security. In other words, the sender would like to avoid anything that is not under control or cannot be directly verified by the sender. Doing a background check of the recipient is orthogonal to the PK problem. It does not help nor solve it.

Ed Gerck

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

Reply via email to