gurudevdas at gmail.com
Wed Jan 14 21:54:01 EST 2009
> > So initial message is of the form (encrypt BobPublicKey (list AlicePublicKey
> > MessageBody)) or (list (encrypt BobPublicKey ThrowawaySymmetricKey) (encrypt
> > ThrowawaySymmetricKey (list AlicePublicKey MessageBody)))
> > and subsequent messages would be of the form (sign AlicePrivateKey (encrypt
> > BobPublicKey MessageBody)) or the symmetric key equivalent?
> (encrypt BobPublicKey (list AlicePublicKey (encrypt AlicePrivateKey message)))
> If someone has Alice's public key (many could), he still can't impersonate Alice
> unless he's also obtained Alice's private key.
> > Instead of piggybacking the key exchange on the first message, maybe the
> > sender could include their manifest URL by way of address. So all messages
> > would be of the form
> > (list SenderManifestURL (sign SenderPrivateKey (list (encrypt
> > RecipientPublicIKey ThrowawaySymmetricKey) (encrypt ThrowawaySymmetricKey
> > MessageBody))))
> The identity is the private/public key pair. Key exchange occurs before the
> first message. The manifest file exists to make this easier.
> Privacy is something I'm aiming at. I do not want admins of storage pools to
> read someone's message without that person's permission.
I should fix this: The message in transmission should only identify the storage
pools of the communicators.
To everyone intercepting the message, it appears as a binary blob of random bits
(hopefully). Likewise it would appear as such to the receiver. After decrypting
the message, the receiver would have the ID of the sender (sender's public key)
and a second binary blob. Decrypting the second blob would yield a specific set
of strings that the client understands. This would verify the sender's identity.
So the above transformation could be:
(encrypt BobPublicKey (list AlicePublicKey
(encrypt AlicePrivateKey SpecialStrings)
I hope you understand what I'm aiming for.
More information about the cap-talk