No interface to find your own OTR public key fingerprint

[aaronjacobs]

Whenever initiating an OTR encrypted chat with a buddy for the first time, a dialogue is displayed asking you whether you want to accept their key fingerprint. The idea is that you confirm this with them in person so that you are assured of their identity.

That's a great idea, but the problem is that I cannot for the life of me find my own key fingerprint, which precludes me from confirming it with my buddy. Adium needs to show you your own fingerprint in some manner. Not doing this negates a significant portion of the security effort that OTR represents in the first place.

If there's a way to do this on the command-line or something in the meantime, please let me know. I can find my private key in my Library, but the public key doesn't seem to be stored on the drive.

[evands]

Good point about being able to tell from the initial 'accept fingerprint' dialogue.. will look into that. Once the OTR chat is established, select "Encryption Details..." from the lock toolbar item and you'll be presented both your secure ID and your contact's purported secure ID... at that time, you can contact him/her through another channel and verify that you're talking to the right person. Does that help?

[aaronjacobs]

Good point about being able to tell from the initial 'accept fingerprint' dialogue.. will look into that. Once the OTR chat is established, select "Encryption Details..." from the lock toolbar item and you'll be presented both your secure ID and your contact's purported secure ID... at that time, you can contact him/her through another channel and verify that you're talking to the right person. Does that help?

What exactly is the secure ID in terms of the encryption?

[aaronjacobs]

More specifically, can you point out what in this document corresponds to the secure IDs? Depending on the answer, verifying the secure IDs may or may not be a secure solution.

[evands]

More specifically, can you point out what in this document corresponds to the secure IDs? Depending on the answer, verifying the secure IDs may or may not be a secure solution.

They correspond to the Session IDs in that document. Probably should be renamed to match, in fact.

[aaronjacobs]

Then I'm not 100% sure, but I believe verifying the session IDs wouldn't be a secure solution, as if you are unsure of the authenticity of the DSA key (since you haven't verified its fingerprint) then the DH key is possibly not authentic. And the session IDs are generated from the DH key.

I think basically the only way to have proper assurance of the user's identity is to verify the public key fingerprint, as Adium asks you to do. It would be great if it would show you your own fingerprint both in the preferences somewhere and in the dialogue asking you to verify someone else's (so you can just trade fingerprints with each other).

And the security of this is, of course, assuming that Adium will throw up an alert if a user's public key does not match the fingerprint on file for that user, the way it does when no fingerprint is on file. I assume it would do this, right?

[aaronjacobs]

Now that I think of it, I was wrong before. In order for an attacker to perform a man-in-the-middle attack, he would have to switch DH keys as they go from one person to the other. Since the secure IDs are based on the DH keys on both ends, I guess they wouldn't match if a man-in-the-middle listening attack were being performed.

However, the secure IDs are only valid as long as the DH keys are, and the DH keys seem to be switched fairly often. So the secure IDs at most only validate that one session.

Moreover, the secure IDs matching doesn't seem to be any grounds for assuming that the key fingerprint you accepted is valid. A man-in-the-middle could merely pass the traffic back and forth without trying to read the encrypted data and leaving the DH keys intact, but re-sign the DH keys with his own public DSA key. In this case the secure IDs would match and the attacker couldn't listen in, but you would have accepted the attacker's public key and thus be open to attack the next time if you don't verify the secure IDs (which is a mighty cumbersome thing to do each time - it's much easier to just verify the DSA key fingerprint once).

[Jequirity]

More specifically, can you point out what in this document corresponds to the secure IDs? Depending on the answer, verifying the secure IDs may or may not be a secure solution.

They correspond to the Session IDs in that document. Probably should be renamed to match, in fact.

First, thanks and props for putting OTR into the product itself. It's the only way secure communications can happen and I appreciate the work.

Now, in the OTR protocol the session ID is the output of an SHA-1 hash, 20 bytes long, and each user sees one 10-byte half. What's showing in the Verify dialog is 4 bytes for each side of the conversation.



Is it a substring of the OTR session ID?