Skip to content
This repository has been archived by the owner on Aug 5, 2022. It is now read-only.

Is it possible to change a RSA key passphrase ? #17

Closed
NicolasMassart opened this issue Jan 12, 2016 · 6 comments
Closed

Is it possible to change a RSA key passphrase ? #17

NicolasMassart opened this issue Jan 12, 2016 · 6 comments

Comments

@NicolasMassart
Copy link

Hi,

My usecase is that content would be signed with RSA key in order to be verified with the public part of that key. This is the regular use case.
Signing require the passphrase of the private part of the key.

I would like the user to be able to change the passphrase of the key on a regular basis, but the key itself have to remain the same to avoid the need to sign all the old content again and keep the ability to verify signature with the public key.
Is this usecase (signing + change passphrase) possible with your lib ?

Thanks,
Nico.

@NicolasMassart NicolasMassart changed the title Is si possible to change a RSA key passphrase ? Is it possible to change a RSA key passphrase Jan 13, 2016
@NicolasMassart NicolasMassart changed the title Is it possible to change a RSA key passphrase Is it possible to change a RSA key passphrase ? Jan 13, 2016
@fresheneesz
Copy link

Yes please, this is critical in cases where someone compromises their key

@hesalx
Copy link

hesalx commented Apr 13, 2016

Not going to happen. This lib is a distinct approach from what you want.

Usually, passphrase is used to encrypt an existing private key. Thus, it can be decrypted and then encrypted using different passphare.
This lib utilizes passphase as a seed for random number generator. Thus, private key is uniquely and tightly coupled with its passphare.

Think of it the same way as of a hash function. A hash function deterministically maps its input to some hash. You cannot just change one input to another input, chosen by your wish, and still get the same hash on output.

You would use this lib if you don't want to store private key. Thus, for an end-user of your application, passphase becomes indistinguishable from private key in matter of its usage and purpose. Lost passphrase = lost private key.

The practical applications of this are rare and should be well-thought-out before deployment, I would say. The enthropy of a key is very low (few orders of magnitude lower than should be for strong private key). Such approach is good for proving the knowledge of a passhprase to other party, but really bad for actual data encryption.

If you're already storing private keys, you should consider truly random generation for private keys and some common symmetric encryption with passphrase to secure a private key. Maybe, something like this https://github.com/brix/crypto-js#aes-encryption

@Elmapul
Copy link

Elmapul commented Nov 27, 2016

@arantir
can you use an trully random generation for passphrase and keep this code to generate the private key?

@hesalx
Copy link

hesalx commented Nov 27, 2016

@Elmapul I guess you want to generate a secure (to some extent) RSA key purely on client-side (in other words generate a key with a sophisticated server-side software and send it to the client is not a case for you). If so, then... yes, this can do the trick.
The concerns are how good is the randomness of your passphrase and how good is PRNG implementation in the library (this claim is true for any lib which generates a key from a seed), but I'm not that much of an expert in cryptography to judge.

@fresheneesz
Copy link

@arantir If this is really the way it operates, you should make this much clearer in the documentation. As it stands, a cursory look at this definitely leads people to misinterpret what this library does (as evidenced by the response on this issue)

@hesalx
Copy link

hesalx commented Nov 28, 2016

@fresheneesz Sorry, I'm not the owner or contributor (also have no intention to be the one), just used the lib few times long ago.
The way it operates is described on the front page https://github.com/wwwtyro/cryptico#encryption-technical-documentation

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants