Storable/copyable private key?

[GRAgmLauncher]

How would I store the private key for later decryption? I can easily transfer the public key string, but I don't want to store the RSA key anywhere on a server. However, a user can't just copy the RSA key as text, so how would they retain the private key locally for later decryption?

Can there be a way to convert the private key into something copy-able like base64?

[tracker1]

Cryptico can create a key using a key derivation method against a user's own passphrase... you can use the same passphrase to generate the same key-pair again later.

Cryptico is for asymetric encryption (RSA)... message passing... what you are wanting is an symetric encryption algorithm such as AES. If you're using node, you can use in the built in crypto library's createCipher / createDecipher methods... if you need this client-side, you can use browserify.

Because you are saving user based information, you may want to use a key derivation method for generating an encryption token to use from said user input. You should use something like pbkdf2 if you don't use this library's (passphrase based key derivation function).

• https://nodejs.org/api/crypto.html
• https://github.com/crypto-browserify/crypto-browserify
• http://browserify.org/
• https://www.npmjs.com/package/pbkdf2

[GRAgmLauncher]

Well my intended application is to use asymmetric encryption to initiate a
one-time transfer request. I initiate a request for sensitive info, which
creates a private key for me, and sends the other party my public key with
the request. They then enter the info and send it back to me, encrypted
with my public key, at which point I can use my private key to decrypt it.

I don't want the private key to ever touch or come from the server, it's
strictly in the browser only.

Once the request is finished, the public key is thrown away and the private
key is no longer needed.

On Friday, April 10, 2015, Michael J. Ryan [email protected] wrote:

Cryptico can create a key using a key derivation method against a user's
own passphrase... you can use the same passphrase to generate the same
key-pair again later.

Cryptico is for asymetric encryption (RSA)... message passing... what you
are wanting is an symetric encryption algorithm such as AES. If you're
using node, you can use in the built in crypto library's createCipher /
createDecipher methods... if you need this client-side, you can use
browserify.

Because you are saving user based information, you may want to use a key
derivation method for generating an encryption token to use from said user
input. You should use something like pbkdf2 if you don't use this library's
(passphrase based key derivation function).

• https://nodejs.org/api/crypto.html
• https://github.com/crypto-browserify/crypto-browserify
• http://browserify.org/
• https://www.npmjs.com/package/pbkdf2

—
Reply to this email directly or view it on GitHub
#13 (comment).

[jermaustin]

If I'm understanding you, you have 2 users talking somewhere unsafe (chat, etc), and they want to transfer data to one another securely.

So say user1 wants to initiate a trasfer, you would create a passphrase of "user1RANDOMTEXTHERE" and generate the key off of that then keep the privatekey local to the users browser and send the public to the server to be pushed to user2. user2 then adds the files and crypts them against the public key. user2 then sends the file up to the server for user1 and user1 downloads and decrypts them using the privatekey local to his browser. Say you want user1 to be able to comeback and decrypt the files/info after they already navigated away from the page. Then you will need to store the private key on the localstore for the browser. This is where the security model starts failing. Storing the public key (even locally) is always insecure.

The better way would be to ask user1 to create a unique passphrase for each transfer. It is up to the users to make sure it is unique each time, but that way, they download the file and have to reenter the passphrase.

[GRAgmLauncher]

But if a passphrase is all that's needed to decrypt the data, then an attacker can do password brute forcing from anywhere if they get access to the encrypted text. Meanwhile if you need to use the key, the attacker must first gain access to the computer that will do the decrypting as that's the only place the key is located - hence why keys are inherently more secure than passphrases.

It's up to the end user to secure their private key for decryption - no different than any other SSH key stored on a computer.

A one-time passphrase just to get access to the encrypted data in the first place is fine, but a passphrase as the only means of decryption is IMO much less secure than a temporarily stored local key.

[jermaustin]

But with cryptico the key is generated off the pass phrase. So using cryptico you will always have this same issue. If you want to generate them a random pass phrase that was my first suggestion. Then just display it somewhere and tell them to keep it safe as it will be needed to decrypt the package.

Sent from my iPhone

On Apr 12, 2015, at 11:17 AM, Jon LeMaitre [email protected] wrote:

But if a passphrase is all that's needed to decrypt the data, then an attacker can do password brute forcing from anywhere if they get access to the encrypted text. Meanwhile if you need to use the key, the attacker must first gain access to the computer that will do the decrypting as that's the only place the key is located - hence why keys are inherently more secure than passphrases.

It's up to the end user to secure their private key for decryption - no different than any other SSH key stored on a computer.

A one-time passphrase just to get access to the encrypted data in the first place is fine, but a passphrase as the only means of decryption is IMO much less secure than a temporarily stored local key.

—
Reply to this email directly or view it on GitHub.

[GRAgmLauncher]

Then just display it somewhere and tell them to keep it safe as it will be needed to decrypt the package

But then isn't that the same problem with local key storage? If the user has to "keep something safe", why not the key itself instead of a brute-foricble password? At least then the key can be made to be non-reproducible (e.g. derive it from a very long randomly generated string the user never sees)

[jermaustin]

That's what I meant was generate a random passphrase that generates the key pair. Then display both keys one for them the other for their friend.

Sent from my iPhone

On Apr 12, 2015, at 11:50 AM, Jon LeMaitre [email protected] wrote:

Then just display it somewhere and tell them to keep it safe as it will be needed to decrypt the package

But then isn't that the same problem with local key storage? If the user has to "keep something safe", why not the key itself instead of a brute-foricble password? At least then the key can be made to be non-reproducible (e.g. derive it from a very long randomly generated string the user never sees)

—
Reply to this email directly or view it on GitHub.

[tracker1]

@jermaustin if you are generating a passphrase that is a seed to a kdf (key derivation function)... the encrypted data is no more secure than your random passphrase. beyond that, if both parties know it, they can do either side of this...

You may want to look into something like pgp / keybase.io or similar... I'm not entirely sure wrt your use case... hell even a passworded .zip/7z file via dropbox would work similarly.

[omsigum]

@tracker1 I am not figuring out how to generate the same key, with the user password. How is this accomplished ?

[FarajiA]

I as well was hoping to do this same thing, I'm wanting to store the private RSAKey as an object in localStorage for later usage. I've been able to use JSON.stringify to convert the key to a string, then using JSON.Parse retrieve the object.

Decrypting messages with the stored RSAKey doesn't seem to work unless the passphrase is reused to generate another RSAKey. I'd rather save the RSAKey object than a passphrase but as @tracker1 pointed out a breach of localstorage would result in the same vulnerability.