Public/private key encryption question about forge HOT 5 CLOSED

The crypto stuff looks ok. How you transport the data (concatenation vs. separate properties vs. whatever serialization format) is entirely up to you and your approach seems fine to me. That being said, I'm an implementer of these technologies -- I'm no Bruce Schneier.

What you're doing is very similar to what is in the Web Keys 1.0 specification, an upcoming W3C spec that is part of the Web Payments work (PaySwarm):

https://payswarm.com/specs/source/web-keys/#message-signature-algorithm
https://payswarm.com/specs/source/web-keys/#message-encryption-algorithm

Something to keep in mind is that this approach is only viable if you intend your messages to be transient in nature (it does seem like that's your use case, but I won't presume). Using the same RSA key pair for encryption and authentication becomes dangerous if you develop a need to share or escrow private keys (to ensure that long-lived data can be decrypted, for instance).

from forge.

Thank you so much for taking the time! I am feeling a bit more confident already that it'll actually work out.

In fact what I am doing is storing PBKDF2 encrypted private keys on a centralized server, but I lock them behind throttled bcrypt before retrieval, meaning that, theoretically, nobody even gets his hands on the encrypted keys if not first defeating bcrypt.

Also thanks for the links, I am already checking this out!

from forge.

@dcodeIO, when escrowing keys you should always do so securely -- but that doesn't change the fact that you're escrowing them. Note that anyone who is working on your software (or a potential hacker) won't have to necessarily go through bcrypt to get at the encrypted keys. If you're keeping keys on a centralized server, and those keys can be used as an authentication/authorization mechanism for your users, they need to be aware of that fact and know how to revoke those keys if necessary.

Keep in mind that if you need to revoke a key that is used for authentication but you also need it to decrypt long-lasting data, you may have a difficult problem to resolve. Also make sure that you don't create situations where someone could easily choose the data that they want others to sign -- as this could be a potential attack vector for getting people to unwittingly decrypt data. Padding is meant to help here, but your users should always know what they are signing before they sign it.

from forge.

Ok I see. You probably guessed it already, what I am building is an instant messenger.

Actually the keys are not used for authentication which is done through bcrypt, however secured with the same password as bcrypt. I am planing to offer the option to regenerate keys in case someone feels compromised.

The bcrypt authentication works through requesting a challenge, which is basically the bcrypt salt portion from the server, then hashing it on the client side and sending the hash back, where it's then compared to the stored hash. Everytime when this is done, also an updated hash is transfered that will replace the previous hash based on a new salt. The full hash that's stored on the server is not known to someone on the outside but, like you pointed out, probably to an attacker who has made it to the inside. From the inside he needs to break the PBKDF2 private key, from the outside first bcrypt and then PBKDF2. Do you know of a way to make this even harder from the inside? Like using another in-memory key pair (requested once with a password when a worker node starts up) used by the service itself to decrypt the encrypted private key or something?

Signing is performed on the encrypted data when a user sends a message, solely to make a message validateable. This way around it's always quite random byte data (based on rsa and random one-shot aes) that's signed implicitly. Nothing else is getting signed.

The server itself does not do any cryptography but SSL for the meta data.

from forge.

As there haven't been any more comments here for a while, I'm going to go ahead and close this issue. It can be reopened if necessary.

from forge.