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 #88#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//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 #88: Use a global key.
This would be currently dangerous with both symmetric and asymmetric
cryptography.
#93 #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//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)