Use asymmetric cryptography for authentication

[elieux]

It was mentioned during the discussion on #88. Goal: If an attacker steals a key, he/she can impersonate only one side of the communication. Requires: a good JS library for asymmetric crypthography.

A quick search showed some candidates:

• http://www-cs-students.stanford.edu/~tjw/jsbn/
• http://www.ohdave.com/rsa/
• http://www.hanewin.net/encrypt/rsa/rsa.htm

[pfn]

(copying a comment I made in #88, a huge security risk to keep in mind prior to thinking about implementing this feature)

Possibly, yes. But, there's at least one more consideration: an attacker may be able alter the keepass config to put their own key there. No knowledge of the database password, but now have access to the database once unlocked.

[elieux]

This is not directly related to implementing asymmetric cryptography, but rather to the request in issue #88. This kind of attack (and worse) would be possible even with the current symmetric solution.

I'd like to keep this issue focused on just the cryptography. (Even though it's probable that nobody's gonna work on this unless the concerns in #88 are addressed.)

[pfn]

Actually, against firefox, with a master password set, this kind of attack is impossible in the current implementation. Chrome stands vulnerable, but that could be easily rectified at a cost of adding a user-interaction to unlock the link. The only vulnerable place is the initial key-exchange, but if that were the case, your box is already fully compromised.

Pairing keys are stored within the database, so they are both secure and access-controlled; using a global key would not be.

On Mon, Mar 25, 2013 at 12:32 AM, elieux notifications@github.com wrote:

This is not directly related to implementing asymmetric cryptography, but rather to the request in issue #88https://github.com/pfn/keepasshttp/issues/88. This kind of attack (and worse) would be possible even with the current symmetric solution.

I'd like to keep this issue focused on just the cryptography. (Even though it's probable that nobody's gonna work on this unless the concerns in #88https://github.com/pfn/keepasshttp/issues/88are addressed.)

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/93#issuecomment-15380730 .

[elieux]

I know. I wanted to separate the two issues.

88: Use a global key. This would be currently dangerous with both symmetric or asymmetric cryptography.

93: Use asymmetric crypto: Doesn't worsen security.

You mentioned that there are no good asymmetric cryptography JS libraries. Can you assess the libraries I linked to?

[pfn]

Actually, jsbn looks pretty good, I will consider its inclusion in the future.

On Mon, Mar 25, 2013 at 12:55 PM, elieux notifications@github.com wrote:

I know. I wanted to separate the two issues.

88 https://github.com/pfn/keepasshttp/issues/88: Use a global key.

This would be currently dangerous with both symmetric and asymmetric cryptography.

93 https://github.com/pfn/keepasshttp/issues/93: Use asymmetric

crypto: Doesn't worsen security.

You mentioned that there are no good asymmetric cryptography JS libraries. Can you assess the libraries I linked to?

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/93#issuecomment-15420106 .

[tekmaven]

In doing a little research on this issue, I came across this library: https://www.pidder.com/pidcrypt/?page=rsa. It may be a good idea to evaluate it as well.

[ya-isakov]

I think that RSA is not needed here - you only need suitable key exchange algo. For example, Diffie-Hellman (JS example) or SRP (bouncy castle, JS crypro library). With DH, you have MITM problem, but it can be easily mitigated if you show key, generated on association in browser, to user. This key also should be shown in keepass confirmation window. If user sees mismatching keys, he denies association. NB: only browser-side pubkey needs to be verified. With SRP, keepass can generate password and show it to user. Then, the user should enter it in browser plugin (or vice-versa). BTW, SRP have great features, such as perfect-forward security. This cannot be achieved with plain RSA or DH (without ephemeral keypair)