I have a requirement to encrypt with AES -symmetric- a string and then share the encrypted string with a client.
They know the key (we have communicated over the phone) and they should be able to decipher the encrypted string.
However the Java implementations I have found all require to share the salt (or IV) along with the encrypted document. This defeats the purpose of sharing only the cipher text and a symmetric key (before hand) if I somehow have to send the salt every time.
Am I understanding something wrong? Is there a way to share only the cipher text and the symmetric key?
The purpose of the IV in encryption is randomization. If you use ECB mode of operation, it can leak information about the ciphertexts that are encrypted under the same key. See the famous penguin in Wikipedia mode of operations.
E(k,m) = E(k,m') iff m=m'
The modern modes of operation use IV, as AES-GCM which is in TLS 1.3 cipher suites.
You should tell the big company about the danger. I'm pretty sure that they can easily adapt to your case very easily.
Note: ECB mode can only be safe, if
your data is always different (no pattern)
you generate a new key for every encryption with a key agreement protocol as Diffie-Hellman key exchange, and this is not your case.
Usually the IV is shared by appending it to the cipher text. So, eventually you are sending a single Base64 encoded string.
So, if you are worried about breaking a contract by sending two fields (one IV and one cipher text) instead of sending just one field, let me assure you that you're going to send a single field only. And the decryption logic knows how to extract the IV from the received string and use it in the decryption process.
Note that there are some key distinctions between IV and key:
Key is a secret, IV is not
Many messages can be encrypted with the same key, but IV is different for every new message. The key and IV combination has to be unique for every message and the IV also has to be random
Therefore, you do not share IV the same way as key. Since IV changes for every message, it is actually appended with the cipher text to form a single string which is then sent as the encrypted output. So, the decryption logic takes as input only the key and your encrypted output; it knows how to extract the IV and the cipher text from the encrypted output.
On today's date if anyone needs to encrypt something using AES, the usual choice is an authenticated encryption mode like GCM which provides not only confidentiality but also integrity in a secured way.
Unless the recipient (in your case) is rigidly specifying a particular mode for AES, the default choice would always be AES with GCM. And even if the recipient proposes some mode that is not an authenticated encryption mode, you may consider explaining to them the benefits of using authenticated encryption mode.
You'll find a complete java implementation with detailed explanation here.
You may also want to read this along with the comments to understand it better.
Related
This is an extension of this question: OpenPGP Encryption Using BouncyCastle Lightweight API
My problem is as follows:
I have to generate a PGP encrypted message from a plain text. Because of the key sizes in question the only options I had was to either install the Unlimited Strength policy files or use the lightweight API. Given that I needed the solution to be portable I decided to use the lightweight API.
All solutions that I have found to use the lightweight API use the PGPEncryptedDataGenerator and open a stream to encrypt it (code samples in the other link) however the AES encryption for it uses CFB mode whereas I need to do it in CBC mode.
My Current Approach:
I generated a random 256 bit key and 128 bit initialization vector and used it to encrypt the plaintext. Then I encrypted the key with the public key using RSA. I first wrote the encrypted key and then the encrypted text in a stream, signed it using a private key, created PGPLiteralDataPackets out of it and then compressed and armoured it.
However when I try to decrypt it using gpg, it recognized the private key I signed it with and then it gives me a set of non printable ascii characters, which means that it does not recognize the encrypted part even though the public key is present in its keyring.
This means that I am not constructing the message properly. I would like to know how to construct a PGP message manually using bouncy castle so that the encrypted message created by me will be recognized and decrypted.
My question is how does camel pgp actually work and if my deduction is correct at all, I'm not a java programmer so please note that some of the following text might make no sense.
Does it encrypt the payload with a symmetric key, then encrypts the symmetric key with a public key and sends both to the destination (e.g. ftp server) which then decrypts the symmetric key (session key) and then decrypts the payload with it ? Or does it encrypt the payload with pub key and thats it ? Besides, is any of the keys generated every message ? In other words, lets say we have 20 files in a directory, camel processes them one by one, does this mean that the symmetric key will be generated 20 times or it's only generated once and then reused?
I am trying to find out the best solution to encrypt the messages, it seems it's sufficient to use a symmetric key only (AES) as I can transfer it through a safe channel once and that's it, however the implementation appears to be painful in comparison to PGP (I have to implement a Java tool to generate, save to file and load AES keys, play with initialization vector, HMAC etc.), but on the other hand if the latter creates a different key each time it would be inefficient in my case.
In OpenPGP, you've got two choices, Apache Camel allows both of them:
Hybrid Cryptography
A session key (a new one generated each time) is encrypted using public/private (asymmetric) cryptography. This session key is then used for encrypting the actual information using symmetric cryptography.
This approach combines the advantages of public/private and symmetric cryptography: it enables the advanced key management features of OpenPGP, but does not suffer from the enormous costs of encrypting large amounts of data using public/private key cryptography.
Generating new, random session keys each time is very cheap, as those are mostly a random block of data, and do not involve complex calculations as for public/private key pairs.
Using GnuPG (and probably all other implementations), this approach is used by default when using gpg --encrypt. If you specify the recipient's public key, and no passphrase, you will be using this approach.
Symmetric Encryption
OpenPGP also allows directly generating the session key from a passphrase, which is directly used for symmetric encryption. This disables OpenPGP's key management features. Direct symmetric encryption is rarely used with OpenPGP, but might be handy sometimes.
Using GnuPG, this is achieved by calling gpg --symmetric. If you encrypt (and do not sign), but are asked for a passphrase, you will probably be using symmetric cryptography.
In OpenPGP, public/private key cryptography is never used to encrypt input directly.
I have a UI to add/edit password .These passwords are encrypted using Blowfish in CBC mode and it worked fine but during decryption it required a IV (it threw a parameter missing exception.)
I have used the cipher class while initiating the cipher so this would have taken care of the IV while encrypting.
So my doubt is,
should the IV be same for both encryption and decryption? I read on some pages that while decryption if we use an incorrect IV the first block will be incorrect but the remaining blocks would be correct .Can you explain on this?
IF the IV (in case of encryption and decryption using the same IV) be saved should it be saved as a plain object or encrypted along with the password using some delimiter ?Which will be safer?
Thanks in advance.
Yes, the IV should be the same for encryption/decryption. In CBC, if I recall properly, errors will cascade down the blocks. So the whole message will be wrong if you use the wrong IV.
The IV can be stored in plaintext. If you try and store it encrypted, you'll end up needing to store the IV used to encrypt the IV...
However, it is generally considered a bad practice to store passwords in an encrypted form. If someone were to retrieve you database, they'd only need to find one key to retrieve all the passwords.
The recommended way to store passwords is to use a hash function multiple times, also known as a PBKDF (password based key derivation function), either based on a plain hash or on a hmac function. See the OWASP password storage cheatsheet.
There are primitives for this in java, see the example on this page. (Search for Use a Password Hashing Algorithm and scroll down to the java implementation.)
I have an Android application that communicates with another java application. For the data encryption i use the javax.crypto library to encrypt and decrypt the data with a pre-shared key.
According to this question it's possible to get the source code from an APK file. So if somebody is able to read the source code of my application, he's also able to read/manipulate the encrypted data.
It's probably true, so is there a way to prevent this (additional measures, other security method)? Don't know if it have extra value but here is my encryption code:
private static String IV = "AAAAAAAAAAAAAAAA";
private static String ENCRYPTION_KEY = "0123456789abcdef";
Cipher cipher = Cipher.getInstance("AES/CBC/NoPadding");
SecretKeySpec key = new SecretKeySpec(ENCRYPTION_KEY.getBytes("UTF-8"), "AES");
cipher.init(Cipher.ENCRYPT_MODE, key,new IvParameterSpec(IV.getBytes("UTF-8")));
return cipher.doFinal(input.getBytes("UTF-8"));
EDIT:
Communication is send and recieving by NFC. My main issue is, if someone has the key he's able to read and write (abused) information to the other side (the NFC reader)
The pre-shared key is not safe!
For someone with just little java reverse engineering skills it is a job of five minutes to decompile your APK file and extracting the key. Once this has been done your crypto is effectively useless.
The standard approach to fix this is to use a key agreement algorithm. You can for example use the Diffie-Hellman key exchange to quickly and secure generate a common secret between two devices: Wikipedia on Diffie-Hellman
Build a hash from the generated common secret and use this as your AES encryption key for this session is a lot more secure and doesn't take much work.
If NFC is your transport layer you need bidirectional data exchanges for Diffie-Hellman to work. Therefore Android Beam will not be usable for you. You can however do bidirectinal data-transfer using host based card emulation on one phone and reader/writer mode on the other.
Using encryption when transmitting data over NFC is a good idea by the way, also the communication range is limited to some few centimeters, you can still sniff the communication from a few meters distance. NFC doesn't do any encryption for you.
A last word of warning: Cryptography is hard to do in practice. Before you send out anything of value over a cryptographic link please make sure that you have a good understanding of what you do. I recommend reading this book which is a good and practical introduction of cryptography: Bruce Schneider - Cryptography Engineering
I am currently making an app that will need to save sensitive data in J2ME, either in RMS or using LWUIT's storage class. (For example username and password)
How secure is such an implementation, and what are the steps to take in order to make sure the data is secure and not vulnerable to theft?
RMS is not encrypted - an attacker can easily read off any data. You'll need to encrypt the data - I recommend the Bouncycastle AES provider, but the Java AES provider also works (although it isn't as efficient, and you'll need to enable 256-bit keys on it). See the accepted answer to this question for some example code, I don't recommend changing anything in the code without asking StackOverflow or another good Q&A site first (it's very easy to incorrectly use encryption libraries); the code uses the Java crypto provider, to use the Bouncycastle provider use Cipher.getInstance("AES/CBC/PKCS7Padding", new BouncyCastleProvider()) after you import the Bouncycastle library. Important to note is that the code generates a Keyspec spec from a char[] password - the user will need to enter this password at least once per session in order for you to decrypt the data (you can't store the password on the device, that would defeat the purpose of encrypting the data). Also important is that you'll need to use the same IV (initialization vector) in the encryption and decryption phases; this IV should be unique to each record that you're encrypting (e.g. when you encrypt foo.txt then use a different IV than when you encrypt bar.txt), but it does not need to be secret (you can store it in plaintext alongside the encrypted file). As an added precaution, wipe the char[] password when you're done with it.