I have a question about when AES generate a key and IV how would the user know what the key is or how the program would know which key to use like it is generated. For example like if there is a encryption method that encrypt the file and generate the key and IV. When the program restarts or be used another day they would want to use the decryption but how would you know or the program knows thats the key for that file.
I understand the decryption and encryption by looking at it. I just dont know where the information is store to retrieve the key?
Key management is a large part of any cryptography related protocol. It takes a book or so to explain.
One of the most known methods is using a password (see password based encryption in PKCS#5, where a key is generated from a (stored) salt, number of iterations and of course the password (encoded to bytes). Another option is to store the key on some removable device like an USB key.
Usually the main key is not used to encrypt the data, but an intermediate key called the data or session key is used. For instance PGP encryption generates a data key and encrypts it with a public key of an asymmetric key pair.
Then there are smart cards, TPM modules, HSM's, key containers (possibly provided by the OS), key sharing protocols etc. etc. etc..
So ... it depends.
Sometimes it is easier to think of a key as another secret. By encrypting something you've only "compressed" your larger secret (your plaintext) into a smaller secret (the key) that you have to keep and manage. This secret however may have been generated in advance, or may have been generated by other means. If you just generate your key at the same time and location as your ciphertext, you haven't solved anything yet, you only made your secret smaller.
It's easier for the IV, the IV can simply be stored with (commonly, in front of) the ciphertext.
Related
I look out many password managers like keeper, 1password, secret-in and I am following secret-in password manager to create my own project and trying to add same features, but got stuck at storing the data of users like his/her secrets, payment secrets in encrypted form. I read encryption model of keeper here but still didn't understand. Where to store a server side encryption key?
I have some data that is symmetrically encrypted with a single key in my database. Rather than hard coding it into my code, I am looking for a safer way to store the encryption key. Where can I safely store it?
The approach here is quite simple.
You only send encrypted data to the server for storage/backup.
The encrypted data received doesn't come with a key.
You need to ensure all encryption and decryption occurs locally on the users device. Thus the user needs to supply the key.
Users aren't good at providing high quality key material, so instead, require the user to provide a password, take that password and pass it through a hash-based key derivation function with parameters that make the function slow (high ops, high mem requirements). An algorithm like pbkdf2 with a strong PRF like HMAC-SHA-2 should be sufficient.
Update:
To answer your specific questions, you need to perform the following steps, you will need to use a cryptographic library that supports key derivation from password and symmetric encryption, like libsodium.
request password from user on first use
run this password through key derivation to derive a key from it: https://libsodium.gitbook.io/doc/key_derivation
execute encryption of user data with key: https://libsodium.gitbook.io/doc/secret-key_cryptography
destroy the key and send data to server for backup
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 tried google, but its not what I want. Google says, its a gathering to check how securely a signing key is stored based on distributed access to the key.
I have this class which has 3 Strings(broken key) and respective attributes (key check values, zone key check values, encryption master key). Using which I derive a Master key. I cannot put up the code here, as it violates my security policy. btw this is for smart cards.
If any one has any idea of this, please explain or point me to it.
OK, I'm going to be assuming a simple symmetric key (3DES or AES) split into 3 parts here. I can only answer because I make this assumption.
A key value is randomly generated, this is the key you're going to protect. Lets call this key the master key. A KCV (key check value) is calculated over the master key, so if it is regenerated the correctness of the key can be verified with relatively high certainty without revealing the value itself. The KCV doesn't leak information about the key material itself as the calculation of the KCV is one way.
This key is split into three parts using other random values and XOR. First two other random keys are generated. The third key is calculated to be the XOR of the other keys and the master key. KCV values are calculated and written down. The three keys can now be distributed to 3 different actors. These actors are called key managers in the role they perform in the ceremony. Commonly the key managers secure access to their key.
Now to regenerate the master key each key manager writes down their part of the key. The KCV of the key is verified before proceeding to make sure that no input errors have been mode, or that the value is not that of a different key. Now if you calculate the XOR of the three keys then you'll get the master key again. This value is again compared to the master key.
So that's all there is to it.
With regards to the security of this scheme:
you need all three keys as the other keys basically provide a One-Time-Pad encryption over the key value, which provides a very strong notion of security
the common KCV is a dangerous notion, as an encryption of an all zero block - the most common scheme - may leak sensitive information (e.g. for counter mode security with a zero nonce and counter). E.g. a HMAC over an empty value may be a better idea
obviously you need a secure random number generator to generate the keys or your scheme is likely to be insecure
it will be hard to generate the wrong key on purpose; commonly the KCV is three bytes, so the chance of one or two people colluding and generate the KCV of the master key is 1 in 2^24 (2^24 is over 16 million).
Key Ceremony in cryptography means that how you will activate your Signing key for different purpose like CA key when issuing a certificate. Key Ceremony have very strong security level that a key is activate with m of n rule, key is stored on secure physical location in Laptops or in HSM(hardware to store keys).
For more detail see WebTrust Principles and Criteria for Certification Authorities – v2.2 document ,download from http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf, in section 4.4 CA Key Usage
On a high level, It's a process of rotating the cryptography keys on Production/UAT environment between two entities and then one entity send a request to another entity to make a session between them with the help of the keys. Keys can have certain roles to encrypt/decrypt the message, to check the integrity of the message e.t.c.
I have a file encrypted with AES using a 256-bit (or 128-bit) key. Passing to and asking the file owner to keep the 256-bit key would be humanly difficult.
How can a more friendly password be used by the owner to remember or retrieve the actual 256-bit key?
For this kind of issues, we have Key Derivation Functions (KDF), as Argon2, PBKDF2, or BCrypt. Argon2 was the winner of Password Hashing Competition. You can see a detailed answer in crypto.stackexchange
In your case, first, you need to choose a password, and use it to generate a key by a KDF for the AES encryption then use this key to encrypt. Depend on the security you may use the random input to increase the entropy, though it will be hard to remember, too.
You can also encode the AES key into base64, however, it will not be easily remembered either.
Note: you can also transfer it with a small Veracrypt Volume.
The RSA algorithm is used for encryption (plain text to cipher text) and decryption (cipher text to plain text) of data. What is the need for using public keys in these sites; why is data encrypted as everything is viewed by everyone?
Why do we need to use public key cryptography in Google; how does it provide security?
What is the need for using public keys in these sites?
It is required to set up a shared secret (a big random number) that is used for further symmetric crypto. Public-private key crypto allows one to share a secret message (symmetric key material) even when each and every message is monitored and eavesdropped. See Hot does SSL works? for more info.
The problem with public-private key crypto is that it is dead slow, whereas symmetric crypto is dead fast. The benefit is that public-private key crypto uses two keys for encryption and decryption and this is what allows to securely share a secret through the insecure channel, whereas symmetric crypto uses a shared key for both operations and you need both parties to have the same shared key.
Why is data is encrypted as everything is viewed by everyone?
When data is encrypted all that an observer can see is pure random noise. An observer cannot understand anything from the encrypted communication. Unless storing encrypted communication, like NSA does, and later asking Google and other companies for their private key. In this way they can decrypt old communication.
Why do we need to use public key cryptography in Google; how does it provide security?
Many agencies would like to know what people search for: "how to make a bomb", political disputes, etc. Advertisers would like to know what people interested in so that they can bring relevant ads. If something is provided to you for free, you are the product. You sell your information (your interests) and when this is done on a global scale suddenly huge money become involved.
Public-private key crypto in this sense provides privacy. Only you and the server can understand the traffic, but no one else: no intermediate hubs, your ISP or government body.
Before Facebook switched to SSL-by-default, all traffic was indeed plain text. This made it possible to build a graph of connections on a truly global scale. The rational I guess was to possibly aid anti-terrorist forces to catch the bad guys. From the other side all population's activities were tracked. See PRISM for more info.