When talking about asymmetric encryption it is often said that due to some reasons you should not encrypt your entire message asymmetrically, e.g. performance considerations.
The usually suggested workflow is:
Create a random key for symmetric encryption
Encrypt the message using this random key
Encrypt the random key using asymmetric encryption
Send the encrypted message and the encrypted key to the recipient
So far, so good.
Just two questions:
How do I send the encrypted message and the encrypted key in combination? Is there a standard for that? Or am I completely free on how to do this? (I'd prefer a standard if there is one).
Is there any best practice on how to create the random key? To be more specific: Is there a specific function in OpenSSL that should be used for that?
This was answered in comments. I would better recommend to check OpenPGP - it is somehow easier to understand, CMS has a huge ASN.1 structures overload.
Random key just should be completely random byte string, generated from good random source.
Related
My question is that, suppose you have some AES-ECB encrypted hash and you want to decode it. You are also given a bunch of example plaintexts and hashes. For example:
I want: unknown_plaintext for the hash given_hash
and i have a bunch of known_plaintexts and hashes that have been encrypted with the same secret key. None of them (obviously) are the exact same to the given hash.
Please let me know if you can help. This is not for malicious intents, just to learn how Cryptography and AES systems work.
This is not computationally feasible. I.e., you can't do this.
Modern encryption algorithms like AES are resistant to known-plaintext attacks, which is what you are describing.
There has been some past success in a category called adaptive chosen plaintext attacks. Often these exploit an "oracle." In this scenario, an attacker can decrypt a single message by repeatedly asking the victim whether it can successfully decrypt a guess generated by the attacker. By being smart about choosing successive guesses, the attacker could decrypt the message with a million tries or so, which is a relatively small number. But even in this scenario, the attacker can't recover the key.
As an aside, ciphers don't generate hashes. They output cipher text. Hash functions (aka message digests) generate hashes.
For any respectable block cipher (and AES is a respectable block cipher), the only way to decrypt a ciphertext block (not "hash") is to know the key, and the only way to find the key from a bunch of plaintext-ciphertext pairs is by guessing a key and seeing if it maps a known plaintext onto the corresponding ciphertext. If you have some knowledge of how the key was chosen (e.g., SHA-256 of a pet's name), this might work; but if the key was randomly selected from the set of all possible AES keys, the number of guesses required to produce a significant probability of success is such a large number that you wander off into age-of-the-universe handwaving.
If you know that all the encrypted hashes are encrypted with the same key you can first try to find that key using your pairs of plaintexts and encrypted hashes. The most obvious way to do that would be to just take one of your plaintexts, first hash it and then try out all the possible keys to encrypt it until it matches the encrypted hash that you know. If the key you're looking for is just one of the many many possible AES keys this is set to fail, because it would take way too long to try all the keys.
Assuming you were able to recover the AES key somehow, you can decrypt that one hash you don't have a plaintext for and start looking for the plaintext.
The more you know about the plaintext, the easier this guesswork would be. You could just throw the decrypted hash into google and see what it spits out, query databases of known hashes or make guesses in the most eduated way possible. This step will again fail, if the hash is strong enough and the plaintext is random enough.
As other people have indicated, modern encryption algorithms are specifically designed to resist this kind of attack. Even a rather weak encryption algorithm like the Tiny Encryption Algorithm would require well over 8 million chosen plaintexts to do anything like this. Better algorithms like AES, Blowfish, etc. require vastly more than that.
As of right now, there are no practical attacks on AES.
If you're interested in learning about cryptography, the older Data Encryption Standard (DES) may actually be a more interesting place to start than AES; there's a lot of literature available about it and it was already broken (the code to do so is still freely available online - studying it is actually really useful).
A question for cryptography experts. Imagine we have a conceptual Notes.app:
There are notes (title|content) stored as AES-256 encrypted strings
Application has to present a list of all notes (titles) in a list on its main window
Every title|content is encrypted with a key, generated from a password and a salt
Let's imagine the key generation algorithm takes ~80ms on a mobile device to generate a key
With the following conditions, it would take almost 1 second to decrypt 10 note titles. But what if there are lots of notes?
My 2 pennies on the problem: Encrypt all notes with different initialization vectors, but also with identical salt. That would allow me to generate a decryption key only once and decrypt lots of notes fast.
The question: doing so we would end up with lots of different notes, encrypted with an identical key. Does that somehow compromise the security of AES encryption? Is it possible that knowing there's a bunch of files with not just identical password, but also identical salt somehow makes it possible to crack the encryption?
Thanks for your thoughts
AES-256 do not use a salt. But I guess you use the salt together with the password in a PBE algorithm to generate the key. Usually this kind of PBE algorithms are constructed to be computational expensive - thus the 80 ms you see on your mobile.
When encrypting different messages, you could instead of using different salts to create different keys, just use different initialization vectors (IV) but the same key. The different IV ensures that messages that starts with the same block encrypts to different messages.
I have an AES256 key that I use for encrypting SSNs in my application. Now I need to encrypt the security answer.
Is it advisable to use different keys to encrypt each field or can I use the same key to encrypt multiple fields?
We have one key for most encrypted fields and another for a few extra sensitive fields. The thought behind it is if someone gets the common key, they still would not have access to the most sensitive information.
I have no idea how this fits in "best practices", but it has worked well for us so far.
Regardless of what you do, someone determined to hack it will find a way. You just need to find the balance and level required for the type of information you are storing. When it comes to SSN and other personal information like that, it is hard to be "overly secure".
As long as you keep to best practices it is possible to use the same key for encrypting multiple fields. With best practices I mean that you need to use a random IV if you are using AES CBC encryption.
Note that the key size of AES is not that important. Having a good key infrastructure, good server security and a cryptographically secure protocol is much more important. AES-128 or even triple DES is almost infinitely safer than AES-256 if the latter is deployed improperly.
I'm some newbie of data encryption. I goggling data encryption and mostly found md5 and SHA algorithms.Which technology do you consider to be the best for data storage/security and why?
MD5 and SHA are hash functions, they create fingerprint - fixed-length representation - from the bunch of data. For example, they are extensively used as a way to check consistency of your iso image downloads for many open-source products, but this means you can use them to create fingerprints from any selection of bytes. So they do not encrypt.
If you want to encrypt, you should check for encryption algorithms. The most feasible now I believe is AES (Advanced encryption Standard) if you look for symmetric encryption algorithms (eg. where key for encryption and decryption is the same or easily computed one from another) or RSA if you look for asymmetric (where you have 2 keys - public and private, and compute private key from public is hard task).
If you are about to create digital signatures, you may want to check things like DSA (digital signature algorithm) and ECDSA (DSA over elliptic curves.). Note that asymmetric algorithms work over numbers with extended precision - like 512, 1024, 2048 bits and so on. You need special libraries that can handle such numbers. If you use C++ I can recommend you trying Crypto++. Find something similar for other languages.
I hope this was useful for you.
If your data is password and you want to store it some where then Use MD5 or SHA Hash.
There are two advantages of these.
A hash can not be decrypted to recover old value so your password will never ever will be cracked even if you provide MD5/SHA hash of password to some one :)
A hash of particular string will be always same so you can compare passwords based on Hash.
AES :
Symmetric algorithm so faster
Use with PKCS5Padding and CBC mode
Always store IV
Symmetric so you need same key while you are decrypting encrypted text so you can not at all share keys.
RSA
PKI Infrastructure to exchange Keys
Slow
There are other algorithms also Like DES(Not So Secure), 3DES(Often called Tripple DES- Not enough secure compared to DES)
First off, I would like to ask if any of you know of an encryption algorithm that uses a key to encrypt the data, but no key to decrypt the data. This seems highly unlikely, if not impossible to me, so sorry if it's a stupid question.
My final question is, say you have access to the plain text data before it is encrypted, the key used to encrypt the plain text data, and the resulting encrypted data, would figuring out which algorithm used to encrypt the data be feasible?
First off, I would like to ask
if any of you know of an encryption
algorithm that uses a key to encrypt
the data, but no key to decrypt the
data.
No. There are algorithms that use a different key to decrypt than to encrypt, but a keyless method would rely on secrecy of the algorithm, generally regarded as a poor idea.
My final question is, say you have
access to the plain text data before
it is encrypted, the key used to
encrypt the plain text data, and the
resulting encrypted data, would
figuring out which algorithm used to
encrypt the data be feasible?
Most likely yes, especially given the key. A good crypto algorithm relies on the secrecy of the key, and the key alone. See kerckhoff's principle.
Also if a common algorithm is used it would be a simple matter of trial and error, and besides cryptotext often is accompanied by metadata which tells you algorithm details.
edit: as per comments, you may be thinking of digital signature (which requires a secret only on the sender side), a hash algorithm (which requires no key but isn't encryption), or a zero-knowledge proof (which can prove knowledge of a secret without revealing it).
Abstractly, we can think of the encryption system this way:
-------------------
plaintext ---> | algorithm & key | ---> ciphertext
-------------------
The system must guarantee the following:
decrypt(encrypt(plaintext, algorithm, key), algorithm, key) = plaintext
First off, I would like to ask
if any of you know of an encryption
algorithm that uses a key to encrypt
the data, but no key to decrypt the
data.
Yes, in such a system the key is redundant; all the "secrecy" lies in the algorithm.
My final question
is, say you have access to the plain
text data before it is encrypted, the
key used to encrypt the plain text
data, and the resulting encrypted
data, would figuring out which
algorithm used to encrypt the data be
feasible?
In practice, you'll probably have a small space of algorithms, so a simple brute-force search is feasible. However, there may be more than one algorithm that fits the given information. Consider the following example:
We define the following encryption and decryption operations, where plaintext, ciphertext, algorithm, and key are real numbers (assume algorithm is nonzero):
encrypt(plaintext, algorithm, key) = algorithm x (plaintext + key) = ciphertext
decrypt(ciphertext, algorithm, key) = ciphertext/algorithm - key = plaintext
Now, suppose that plaintext + key = 0. We have ciphertext = 0 for any choice of algorithm. Hence, we cannot deduce the algorithm used.
First off, I would like to ask if any of you know of an encryption algorithm that uses a key to encrypt the data, but no key to decrypt the data.
What are you getting at? It's trivial to come up with a pair of functions that fits the letter of the specification, but without knowing the intent it's hard to give a more helpful answer.
say you have access to the plain text data before it is encrypted, the key used to encrypt the plain text data, and the resulting encrypted data, would figuring out which algorithm used to encrypt the data be feasible?
If the algorithm is any good the output will be indistinguishable from random noise, so there is no analytic solution to this. As a practical matter, there are only so many trusted algorithms in wide use. Trying each one in turn would be quick, but would be complicated by the fact that an implementation has some freedom with regard to things like byte order (little-endian vs big-endian), key derivation (if you had a pass-phrase instead of the actual cryptographic key itself), encryption modes and padding.
As frankodwyer points out, this situation is not part of usual threat models. This would work in your favor, as it makes it more likely that the algorithm is a well-known one.
The best you could do without a known key in the decoder would be to add a bit of obscurity. For example, if the first step of the decode algorythm is to strip out everything except for every tenth character, then your encode key may be used to seed some random garbage for nine out of every ten characters. Thus, with different keys you could achieve different encoded results which would be decoded to the same message, with no key necessary for the decoder.
However, this does not add much real security and should not be solely relied on to protect crucial data. I'm just thinking of a case where it would be possible to do so yes I suppose it could - if you were just trying to prove a point or add one more level of security.
I don't believe that there is such an algorithm that would use a key to encrypt, but not to decrypt. (Silly answers like a 26 character Caesar cipher aside...)
To your second question, yes; it just depends on how much time you're willing to spend on it. In theoretical cryptography it is assumed that the algorithm can always be determined. Whether that be through theft of the algorithm or a physical machine, or as in your case having a plain text and cipher text pair.