I am learning about hashing and encryption and can’t seem to understand this:
Client: New user logs in => Creates password => Sent to a server in plain text
Server: Server generates a random "salt" => plain text and salt are unified => Hash function (e.g. SHA-3) hashes the password+salt into a hash => Hash is stored in DB.
Client: Same user logs out and logs in => Password sent to a server in plain text.
Server: Password needs to re-add the same salt it generated when creating the account to get the same hash.
How does the server generate that same random and unique salt?
Is the salt stored on a different DB altogether?
If a DB is compromised the hackers would also gain access to the salt and just brute force rainbow tables with the salt and unhash them.
The salt that was randomly generated must be stored in the database and linked to the user that logged in. It could be simply added as another column in the user table.
In a typical setting, the salt and the password (or its version after
key stretching) are concatenated and processed with a cryptographic
hash function, and the output hash value (but not the original
password) is stored with the salt in a database
Source: https://en.wikipedia.org/wiki/Salt_(cryptography) retrieved 19/02/21
The generation of the salt depends on which technology you are using. The following stack overflow answer has an example for PHP:
Can we use uniqid() to generate a unique Salt in PHP
The password should also never be sent in plain text to the server. This can be done via HTTPS for example
When the user logs in again. The password is sent to server side along with email.
The email is used to fetch the user record and then the Hash value saved against that email is compared with the new hash (salt + password entered).
The validate function method matches the 2 different hash values and checks if password entered was same or not.
For example, I am using bcrypt in Node JS and it has a method compareSync which matches the entered password with the saved hash
bcrypt.compareSync(password, databaseHash);
I've been doing some searching and still do not know if this is possible. What I want is for a message to by encrypted by our system and decrypted by a "master key" and also a 3rd party.
This encrypted message needs to be decrypted by 2 entities
-A 3rd party (which we want the control to shut off their ability to decrypt)
-Our system (which we want to always be able to decrypt no matter what, master key?)
From some research I was doing there is a concept of master key and derived keys
Does this following system exist?:
Master Key - can decrypt anything encrypted by derived keys
DerivedKey1 -> Encrypt data with this key and be able to decrypt with Master Key OR DerivedKey1
DerivedKey2 -> Encrypt data with this key and be able to decrypt with Master Key OR DerivedKey2 but NOT derivedKey1
Any terminology I should be using to search for answers would be helpful, also any crypto systems that do this already would be great to know.
Yes, I mean deny any new messages sent from our system to be decrypted
You can encrypt the content with a random key (data key).
Then you can encrypt the data key for each intended recipient (master key and any 3rd party) using its shared or public key.
I have many methods like the below which uses X509Certificate2.PrivateKey
public SomeValue DoSomething(X509Certificate2 cert)
{
// do something that needs the cert.PrivateKey
}
They are working well so far with certificates that are stored in the Windows certificate store whose private keys are accessible. Problem now is that I need to support certificates stored in HSM devices and Azure Key Vault HSM where the private keys can't be loaded into memory (and thus the PrivateKey property is null).
I'm looking for a way to avoid changing signatures of my public methods. If the PrivateKey property is virtual, I would be easily make sub classes and return appropriate AsymmetricAlgorithm implementation for each store type (to be clear, for example in Azure Key Vault HSM, the AsymmetricAlgorithm will be an implementation that calls Azure Key Vault to do signing). Btw, the setter of the PrivateKey property doesn't allow me to set my custom AsymmetricAlgorithm.
Another problem is that the PrivateKey property is out of favor now and the GetRSAPrivateKey extension method is recommended.
Is there any trick that I can use to let an X509Certificate2.PrivateKey or the GetRSAPrivateKey extension method returns an AsymmetricAlgorithm of a type that I want?
When using KV, RSA Private Keys don't leave KV, when you get a 'key' back from KV, you really get a key ID, not the key. You will need to export the cert as a PFX file.
I'm working on creating small relay stations out of tiny embedded Linux boxes. They have some sensors connected to them and transport data back to a server via HTTP POST. Right now the server just accepts their message, along with a unique ID (the MAC address of eth0).
I want to expand this to include some type of security. I want to be able to deploy these little devices with minimal configuration. I'd like to copy a base firmware to the device, hook them up in the field, and they self-register. The first time they connect, I'd like the server and device to do some type of negotiation where I can store a fingerprint. Subsequent requests I could then authentication/verify the device using that fingerprint.
That way, once a device registers with its unique ID, I can be assured all data from that ID is from the same device. If a rouge device or set of devices does register, I'll just delete them (I store IPs to so I can delete by unknown ranges and block them).
My question is what's the best way to go about doing this? I think back to the idea of SSH fingerprints, where the first time you connect to a server you get a server fingerprint. If a future request yields a different fingerprint, you get a huge warning and have to manually delete the fingerprint out of your authorized_keys file if the server's keys have actually regenerated (e.g. you did a reinstall without saving your old SSH keys).
Is something like this possibly with HTTP, possibly avoiding having to use preshared keys?
If it matters, the clients are running Python2 and the server they connect to is written mostly in Scala on Tomcat.
Basically, all you need to do is tell the server the public key, and then sign all of your messages with it. If you don't want pre-shared keys, then the server cannot be assured that someone new who is registering is actually one of your devices. You can still validate that the message came from the same device that originally registered with that identifier, however.
The process basically goes like this:
Client generates a new key pair (e.g. an RSA public/private key pair).
Client registers with server, sending its public key. The server stores this public key.
When the client sends a message, it generates a signature of its message, which it attaches to the message. When the server receives the message, it validates the signature to ensure that the message was sent by someone holding the corresponding private key.
The code for this in PyCrypto goes something like this:
Generate key pair
from Crypto.PublicKey import RSA
key = RSA.generate(2048)
private_key = key.exportKey()
public_key = key.publickey().exportKey()
# private_key is a string suitable for storing on disk for retrieval later
# public_key is a string suitable for sending to the server
# The server should store this along with the client ID for verification
Generate signature
from Crypto.PublicKey import RSA
from Crypto.Hash import SHA
key = RSA.importKey(private_key)
# where private_key is read from wherever you stored it previously
digest = SHA.new(message).digest()
signature = key.sign(digest, None)
# attach signature to the message however you wish
The server should load the public key as it has previously stored, and use a "verify" method provided by the Scala/Java crypto API you use, and accept the message only if it succeeds.
It is important to understand the caveats of each approach, as various techniques only protect against certain types of attacks. For instance, the above approach does not protect against a "replay attack", in which an attacker records a message with a certain meaning and then re-transmits it to the server at a later time. One way of protecting against this would be to include a timestamp in the message which is hashed; another would be to use an appropriately encrypted transport (e.g. SSL/TLS).
According to wikipedia (and other sources), asymmetric encryption always works like this:
Party A has a public and private key
Party B encrypts stuff with A's public key
Party A decrypts stuff with their private key
However, I don't want party A to be able to encrypt their own data and only want to them to be able to decrypt it. Using the asymmetric logic this would result in:
Party A has a private key
Party B has a private key (which is party A's public key)
Party B encrypts stuff with their private key
Party A decrypts stuff with their private key
We will be using this for some sort of license generation/checking. Our clients may not generate a license, but the license file must be readable on the client side.
Is this still asymmetric encryption or should I be looking at different methods?
Party A being able to encrypt messages using the public key is absolutely no problem.
Only you could decrypt them (with your private key) and since you have no reason to do so encrypting something with the public key embedded in your application would cause no harm - just a bunch of useless data the user has since he cannot decrypt it.
For the licensing you simply encrypt (or sign - that's enough and then people will be able to read the restrictions etc in the license file but not modidy them) your license file using your private key. The application then decrypts the file using the embedded public key (or validates the signature).
A user extracting the public key and signing a custom license file with it could not use it since it would only work if your private key was embedded in the application (since that's the key necessary to decrypt something encrypted with the public key).
However, he could very well replace your public key with a custom one (where he has the private key, too) and then sign/encrypt his own license file using his private key. That's not a cryptographical issue though - you simply need to add some anti-cracking/modification measures to make it harder to replace the embedded public key. You could do some checksum validations for example.
You have your private key in the safe, and publish your public key. When you create a license you encrypt it with your private key. The client can only decrypt it with your public key.
If you want to restrict your license to a client, ask the client to generate their keypair, and send their public key to you. You then encrypt the license with their public key, then sign it (or encrypt it again) with your private key.
When the client receives the license they will have to
1. verify the signature of (or decrypt) the license you sent them
2. decrypt the verified data using their own private key.
This ensures that 1. only you can send them the license and 2. only they can decrypt it.
What you'd generally do is generate you license on your side, and encrypt it with your private key. Then your client can read it using your public key. This is (very broadly speaking) how certificate schemes (such as used in secure online browsing with HTTPS) work. And yes, that still absolutely counts as asymmetric encryption.
Based on what you're saying, asymmetric encryption is still what you want, it just needs to be done in a different way than you're used to thinking about it.
Let's say you generate a key pair for A. You send A one half of the pair: it doesn't really matter but we'll call it the private half. You encrypt using the public half and send it on to A. Then A can decrypt it. But A won't be able to encrypt a message that appears to come from the A public key since they only have the private half of the key and you can't figure out the other half of the key if you only have half of it, no matter which half you have. So A could only encrypt messages that could be decrypted by the public key that you have kept as a secret.
Of course, as other posters have already said, there are better ways to set up this protocol. Just trying to explain why this is not really an issue once you understand the details of asymmetric encryption and look past what we like to call the key halves and how we usually use them.
You could have a look at Rhino licensing : http://hibernatingrhinos.com/open-source/rhino-licensing/introduction
The other answers already said how to do it ... here just a note that (at least with RSA) the scheme you described in your question is not secure, if it depends on B's key staying secret.
For RSA, the public and private keys are really asymmetric, and you can't simply swap them and expect the same security properties.
If your party B (Bob) encrypts multiple messages with the same public key, an attacker which reads these (ciphertext) messages can with little effort get your public key. The attacker does not get the plaintexts or the private key, but the public key will always become really "public".
For A (Alice), it is even possible to create the public key from the private one, without any message being encrypted with the public one.
I suppose similar caveats are there for other asymmetric cryptosystems - always use them only like they are specified, and proven.
In this case, you would combine two key pairs: B's one to sign/verify the message (to make sure the message was sent by B), and A's one to encrypt/decrypt the message (to make sure only A can read it).
Yes. You can do it with RSA - to do a Diffie-Hellman-like exchange, because not only do the keys from 1 associated pair commute, but keys from different keypairs can commute as well.
alice -> bob: alice.pub
bob -> alice: bob.pub
alice: r = random.secret()
alice -> bob: ( r * (alice.priv * bob.pub) )
bob: r = ( (r * (alice.priv * bob.pub)) * (bob.priv * alice.pub) )
Notice that we did something odd here. We mixed RSA operations from different keypairs in one operation. The objects in parenthesis are effectively a new virtual RSA key, and neither one of these keys is public. Had we tried to create that RSA key directly, either alice or bob would know both keys of the pair. This keypair is effectively a secret key where you write to one end and only the other side can decrypt it, yet you cant decrypt what you wrote yourself, and nobody else can encrypt messages to the other side.
I have never seen anyone mix keypairs like this, but I tested this by writing the code. I had to do something unusual though because normally, applying the private key to the message is for 'signing'. But signing usually hashes the secret and applies the private key to a hash of it; something we do not want. So in my code, once I had the RSA components (D,E,N) extracted into arbitrary precision numbers... ie: decrypt,encrypt,modulus ... I just did:
wormholeSend(me,you,msg) =
(((me ^ {me_D}) \% me_N) ^ {you_E}) \% you_N
The thing that makes it a little tricky is that E (encrypt exponent) is actually a predictable value, but the modulus N is in the public key (E,N). D is private to each party. We need to be careful here, because you and I have a different modulus N.
I did this because I wanted a system where a program is authorized to encrypt keys that can be decrypted by users. Doing this, the user cannot encrypt keys, and the program cannot decrypt them.