I was going through some questions and one of the questions made me confused on which asymmetric encryption to be using.
The question is as follows.
A student creates a service for multiplication. It takes two numbers and then returns the result of the multiplication. The student claims that you can send the numbers to be multiplied encrypted by a suitable algorithm and the service would send you a product encrypted as well.
In other words you would send them E(x1) and E(x2) and the value you get from the service would be E(x1*x2). You can decrypt this value to get the product. The students service would have no idea on what numbers you had multiplied.
I'm leaning towards RSA. However RSA would require the receiving party to decrypt the values before multiplying them, but that is not to be done.
Related
it is a question I have. I am not expert in this subject, so please, be kind on the answer.
I understood the homomorphic encryption process allow to read a message as if it has been decrypted, but it will do so without removing the protective layer that the encryption process placed on it.
Let's suppose the word "TESTE" is cryptographed, and a homomorphic encryption is done on that encrypted word.
My question is:
Homomorphic will understand the "meaning" of encrypted text? Homomorphic will know that the encrypted word is also "TESTE" ?
Thank you.
Let me give you a different example. I'm not sure the example can be implemented with today's systems. But it illustrates it anyway:
Party A has 10 numbers and encrypts them.
The encrypted numbers are given to party B.
Party B calculates the sum of the 10 numbers. The result is encrypted data.
Party A is given the encrypted result.
Party A decrypts the result.
The main feature is that party B does not need to decrypt the 10 numbers. Futhermore, the encryption is maintained throughout the entire sum calculation. Therefore, party B has neither knowledge of the input numbers nor of the calculated sum because all operations are carried out on the encrypted data.
I understood the homomorphic encryption process allow to read a message as if it has been decrypted.
No. Homomorphic encryption is public key encryption that allows someone to evaluate (technically circuit evaluation) on the encrypted data without accessing the data. The good side, the client can give the heavy process to the cloud without thinking that it's data is compromised as long as the scheme is not broken.
To understand the FHE, we can look at the textbook RSA, which has no padding. Textbook RSA enables multiplication that is if you multiply two the ciphertexts then decrypt you will get the multiplication of the plaintexts. So if you want to multiplication of your data on the cloud just send your data encrypted with RSA.
RSA only multiplies but there is no other operation and this called partially homomorphic.
There are other public key cryptosystems that support only one operation, for example x-or. This can be used to verify fingerprints on the cloud without revealing the data to the cloud.
If two operations are performed then it is called Fully-Homomorphic and we can build an arbitrary circuit, in theory.
The main idea is semantically encrypting your data (input for the calculation), then send the circuit (the operation you want to be performed) and send to the cloud to calculate with your public key. The cloud calculates the circuit and returns back to you. Only, you can decrypt with your private the return to get the result.
The main point is the calculation is done without accessing the data. As long as the Cryptographic primitives are not broken, no one will access your data.
Note: The breakthrough of Gentry's seminal work is finding a novel way to deal with the noise which is doubles with multiplication.
I have recently been learning about public/private key encryption in my computer science lessons, and how it works in terms of data encryption/decryption. We also covered how it can be used for digital signatures. However, we didn't go into too much detail on how the actual keys are generated themselves.
I know that it begins with a very large number, which is then passed through some kind of keygen algorithm which returns two distinctive keys, one of which is private and the other is public. Are these algorithms known or are they black box systems? And does one user always have the same pair of keys linked to them or do they ever change at any point?
It just seems like a very mathematical issue, as the keys are linked, yet one is not deducible from the other.
I know that it begins with a very large number, which is then passed through some kind of keygen algorithm which returns two distinctive keys, one of which is private and the other is public.
Well, that's not entirely correct. Most asymmetric algorithms are of course based on large numbers, but this is not a requirement. There are, for instance, algorithms based on hashing, and hashing is based on bits/bytes, not numbers.
But yes, for asymmetric algorithms usually contain a specific algorithm to perform the key pair generation. For instance, asymmetric encryption consists of a triple Gen, Enc and Dec where Gen represents the key pair generation. And the key pair of course consists of a public and a private part.
RSA basically starts off by generating two large random primes, it doesn't start with a single number necessarily.
Are these algorithms known or are they black box systems?
They are known, and they are fundamental to the security of the system. You cannot use just any numbers to perform, e.g., RSA. Note that for RSA there are different algorithms and configurations possible; not every system will use the same Gen.
And does one user always have the same pair of keys linked to them or do they ever change at any point?
That depends on the key management of the system. Usually there is some way of refreshing or regenerating keys. For instance X.509 certificates tend to have a end date (the date of expiry or expiration date), so you cannot even keep using the corresponding private key forever; you have to refresh the certificates and keys now and then.
It just seems like a very mathematical issue, as the keys are linked, yet one is not deducible from the other.
That's generally not correct. The public key is usually easy to derive from the private key. For RSA the public exponent may not be known, but it is usually set to a fixed number (65537). This together with the modulus - also part of the private key - makes the public key. For Elliptic Curve keys a private random value is first produced and the public key is directly derived from it.
You can of course never derive the private key from the public key; that would make no sense - it would not be very private if you could.
In RSA the generated two numbers p and q are very large prime numbers more or less the same size, which are used to calculate N which derives the public/private keys using modulo arithmetic.
The following answer in crypto.stackexchange.com describes in more details how we can start from a random (large) number and use Fermat test and Miller-Rabin tests to reach a number that is very probable to be prime.
I need to encrypt two-way (symmetric) distinct tokens. These tokens are expected to be repeated (e.g. They are people first names), but I do not want an attacker to conclude which encrypted tokens came from the same original tokens. Salt is the way to go for one-way cryptography (hashing).
Is there a method that can work in symmetric cryptography, a workaround or an alternative?
Yes. Properly used, symmetric encryption does not reveal anything about the plaintext, not even the fact that multiple plaintexts are the same.
Proper usage means choosing a mode of operation that uses an initialization vector (IV) or nonce (that is, not ECB), and choosing the IV appropriately (usually random bytes). Encrypting multiple plaintexts with the same key and IV allows this attack pretty much just like with ECB mode, and using a static IV is a common mistake.
As mentioned above, properly utilizing a symmetric encryption scheme would NOT reveal information about the plaintext. You mention the need to protect the users against a dictionary attack on the hidden tokens, and a properly utilized encryption scheme such as GCM would provide you with this property.
I recommend utilizing GCM mode as it is an efficient authenticated encryption scheme. Performing cryptographic functions on unauthenticated data may lead to security flaws so utilizing an authenticated encryption scheme such as GCM is your best bet. Note that this encryption scheme along with other CPA-SECURE schemes will provide you security against an adversary that wishes to learn the value of an encrypted token.
For example, in correctly implemented GCM mode, the encryption of the same last name will result in a different ciphertext i.e GCM Mode is Non-Deterministic.
Make sure to utilize a secure padding scheme and fix a length for the ciphertexts to make sure an attacker can't use the lenght of the ciphertext to learn some information about the contents of what generated this token.
Be careful however, you can't interchangeably use hash functions and symmetric encryption schemes as they are created for very different purposes. Be careful with how you share the key, and remember that once an adversary has knowledge of the key, there is nothing random about the ciphertext.
-NOTE-
Using encryption incorrectly : If every user is utilizing the same key to encrypt their token then they can simply decrypt everyone else's token and see the name that generated it.
To be safe, every user must encrypt with a different key so now you have to somehow store and manage the key for each user. This may be very painful and you have to be very careful with this.
However if you are utilizing salts and hash functions, then even if every user is utilizing the same salt to compute hash(name||salt), a malicious user would have to brute force all possible names with the salt to figure out what generated these tokens.
So keep this into consideration and be careful as hash functions and symmetric encryptions schemes can't be used interchangeably.
Assuming that the only items to be ciphered are the tokens (that is, they are not embedded in a larger data structure), then Inicialization Vectors (IV's) are the way to go.
They are quite simple to understand: let M be your token, padded to fit the block size used in the symmetric ciphering algorithm (I'm assuming it's AES) and IV be a random array of bits also the size of the ciphering block.
Then compute C = AES_ENCRYPT(M xor IV, K) where C is the ciphered data and K the symmetric key. That way, the same message M will not be ciphered the same way multiple times since IV is randomly obtained every time.
To decrypt M, just compute M = (AES_DECRYPT(C, K) xor IV).
Of course, both IV and K must be known at decryption time. The most usual way to transmit the IV is to just send it along the ciphered text. This does not compromise security, it's pretty much like storing a salt value, since the encryption key will remain unknown for everybody else.
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 am currently currently using Rijndael 256-bit in CBC mode to encrypt some data which needs to be sent elsewhere. In order to enhance security, I'm taking a randomly generated SHA-256 hash and using a formula to chop off different parts it to use the encryption key and initialization vector (of course, the hash is sent with the data). The formula to generate the key and IV is fairly basic, and because the code is written in PHP, it's coded into a user-accessible page. What I'm wondering is: is this more or less safe than having one constant key and/or IV?
This is probably NOT the way you wish to go. In essence, it will take a good hacker not to long to figure out your mathematical formula for manipulating the HASH to generate your key and IV. Thus you are essentially sending the keys to the kingdom along with the kingdom itself.
Generally the way this type of operation is done, is to generate a session key (could be the same way you are doing it now), but use a public key encryption method to encrypt that session key. Then you use the public key encryption method to send the session key to the location your data is to be sent. The receiver has the public key and can encrypt the comm. channel session key.
Now both sides have the comm. channel session key and your REAL data can be encrypted using this key as the session key has not been sent in the clear.
Rijindael is an example of a symmetric crypto algorithm, where public key crypto algorithms are asymmetric. Examples of public key crypto algorithms are RSA, ECDSA (Crypto), etc....
On generating short-use keys. Have a long term key. Agree a date format with the receiver. Each day concatenate your long term key with the day's date and hash it with SHA-256 to generate a day key for use on that date only:
dayKey <- SHA256("my very secret long term key" + "2012-06-27")
The receiver will have all the information they need to generate exactly the same key at their end. Any attacker will know the date, but will not know the long term key.
You will need to agree protocols for around midnight and a few other details.
Change the long term key every month or two, depending on the amount of encrypted data you are passing. The more data you pass, the more often you need to change the long term key.