My private key is server-side and the public one are client-side. I use them to sign JWT from my server and sent to my clients, for authorisation. I have now to also encrypt the user password client-side during the authentication using JWE and verify it from server-side.
This two use case have the same requirements: private key is server-side, public key are client-side, and encryption algorithms can be the same. This is why I am thinking to use the same key pair but I am afraid to miss something about security and I would like to have confirmation, is it safe?
As best practice, you should not re-use the same key pair for different purposes. Just have two distinct key pairs, one for digital signatures, the other for public key encryption.
I'm working on a distributed application, and we need a way to authorize clients. Every client has a PGP keypair associated with them, and we require them to enter their private key (which is not stored) through which their pubkey is derived and used to identify clients and modify their fields on the distributed database.
Now, considering user experience, entering a private key on a website whenever you need to do something is troublesome. But we also cannot maintain a central database for username/password based authentication as that creates a single failure point (not what the distributed application is meant to do)
I am hoping there is some way to get an easier to remember human readable descriptor of the private key which can be used to authenticate if something like that exists. Any other ideas are appreciated too.
I'll throw a bunch of ideas to clarify the question:
Are you certain that PGP is suited for your needs?
I feel like you should provide some more details to be sure:
- How are the private and public keys used exactly? I understand the following : user inputs its private key, information is decrypted and modified, public key is deduced from private and used to encrypt the updated information.
- How is this different from using a regular password and being able to authenticate the user and encrypt data?
- You seems to send private keys on the network, and they should remain private.
How you could use a regular password:
User has a password, your application uses a function (e.g sha256, KDF,...) to make it usable by classical encryption algorithms (e.g AES). With the same (not stored) key, you can then encrypt and decrypt datas. You just have to make sure that decryption is valid, by adding a known value at the beginning of the data (e.g a part of the key).
Quick example:
password: "WeakPassword"
key: sha256("WeakPassword"+"MySalt") = 493e3ae...b2eec8ef
Decrypt(data,key)
clearData = "493e3ae{123;456}" //valid, because you can check the beginning
Encrypt(clearData,key)
Advantages: usable passwords, faster symmetric encryption
Use a QR code
If you stick to PGP and have a camera available it is pretty handy.
You could also use hexadecimal, base64, ... but for a 2048 bits RSA key, that still gets you hundreds of characters.
I need to know how this bitcoin exhanges generate the unique address for the new user on their exchanges
For all intents and purposes the addresses are generally generated using a cryptographically secure random number generator.
Some exchanges may resort to a BIP32-style private key derivation in which private keys for user accounts are generated from a single secret, using hardened derivation for each user's key group. But from outside these are indistinguishable from randomly generated private keys, let alone the public keys.
How do the Public key fingerprint and Digital Signature differs ? Or both are same ?
if they are different, what is the application of public key fingerprint ?
Thanks
a public key fingerprint is a short sequence of bytes used to authenticate or look up a longer public key. Fingerprints are created by applying a cryptographic hash function to a public key. Since fingerprints are shorter than the keys they refer to, they can be used to simplify certain key management tasks
A digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit. Digital signatures are commonly used for software distribution, financial transactions, and in other cases where it is important to detect forgery or tampering
A public key fingerprint is a short version of a public key which is used to authenticate a longer public key, if they do not match that means that the longer public key has been tampered with. So basically a digital signature is something that is signed by a user which only that user can sign so you can be sure that it is coming from that user.
So a public key fingerprint is used by a client and the digital signature is used by the server
The fingerprint is the hash of a key. A digital signature is tied to some message, and is typically a one-way encrypted hash of the message.
The two serve different purposes: You can put the public key fingerprint on your card or, if you recognize the other person on the phone, use it to verify you got the right public key(s). It doesn't say anything by itself. The digital signature, on the other hand, says that the message was signed with that key over there, and you don't need any other channel for verification of that fact.
This question already has answers here:
Whose key is used to encrypt a HTTPS response?
(3 answers)
Closed 4 years ago.
What I understand about RSA is that Alice can create a public and a private key combination, and then send the public key over to Bob. And then afterward Bob can encrypt something using the public key and Alice will use the public and private key combo to decrypt it.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
Basically, the procedure is:
The client connects to the server and asks for the server's certificate. The certificate contains the public key and information about the server's identity.
Assuming the client is happy with the server's identity, it generates a random number P and encrypts it with the server's public key.
Only the server can decrypt P (with it's private key - not shared with anybody) so when the client sends the encrypted random number to the server, the server decrypts it.
The client and server both use P to generate a symmetric key for use in a symmetric encryption algorithm, safe in the knowledge that only the client and server know the value of P used to generate the key.
Alice will use the public and private key combo to decrypt it
Alice would just decrypt it with her private key.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it?
Alice would need Bob's public key to send something to him.
Typically, public key encryption is used for authentication, non-repudiation (like signing), and distribution of symmetric keys (which are faster for encrypting/ decrypting long messages).
Simple, you need a key.
SSL/TLS solves this problem by creating a symmetric session key during the connection setup. The public key cryptography is used to establish this session key, which is then used for bi-directional data communication. Read more about TLS
I didn't create this, but someone shared this video with me and it helped the theory make much more sense. As always the devil's in the details (implementation).
http://www.youtube.com/watch?v=YEBfamv-_do
On a general note I struggled to understand Public Key Cryptography for quite a while along with the other elements of PKI such as Digital Signatures and Certificates whilst preparing for Microsoft C# certification.
I came across an explanation in the form of a concise and detailed PDF at cgi.com. I know it's back to good old Alice and Bob! but it really cleared things up for me with its diagrams and notes and also has some thought provoking questions at the end. Definitely recommend it.
Visit http://www.cgi.com/files/white-papers/cgi_whpr_35_pki_e.pdf
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
This is where you're wrong; you do have a private key. As part of the handshaking process, each side generates two keys: a public key and a private key. The client sends its public key to the server, who will use it to encrypt all data sent to the client. Likewise, the server generates both keys and sends its public key to the client, which will use it to encrypt all data sent to the server.
In many scenarios, the asymmetric key algorithm is used only to exchange another key, which is for a symmetric algorithm.
In this situation, Alice would use Bob's public key to encrypt the data and Bob would then decrypt it with his private key.
Essentially, a public key encrypts data and a private key decrypts that data. Since every user has both a public and private key, you can securely send data to any other user.
If you connect to the site of your bank it works a lot of cryptographic things. The most important is that you use public key of the bank to send a piece of information to the bank, because in every SSL (https) connection server send to client it's public key packed as a certificate.
Usage of certificate and world wide PKI is important. You want be sure, that if you gives to the bank your bank pin, that on the other side is really your bank and not an other person. This will be solved, because on every computers there are a small number of public keys of well known organisations (like VeriSign) and bank send you not only his server public key, but a certificate. certificate is a message signed by VeriSign for example, which say "this public key is really from the bank XYZ". So because you have public key of VeriSign you can first verify, that server certificate of the bank is correct. So you can be sure, that you communicate really with your bank.