I am using password based encryption. My initial thought was to use AES to encrypt the file which contains passwords. Turns out password based encryption does not support AES. It uses DES. AFAIK des is not secure. Is PBEWithMD5AndDES secure enough to thrust my data or should i look for another implementation?
It appears from your comments that what you would like to do is to encrypt a file which contains sensitive information, using a password-based encryption scheme, with a password provided by the user at decrypt-time. The sensitive information in this case also happens to be passwords, but that isn't really relevant. (You should probably update the question to make this more clear).
You are doing the right thing, your problem is just that the SunJCE Java cryptography provider doesn't support AES for password-based encryption. You need to use an alternative provider which does: for example, you could use the Bouncy Castle provider with the algorithm "PBEWITHSHA256AND128BITAES-CBC-BC". (Despite the whimsical name, Bouncy Castle is well-respected).
As for "is DES secure enough for my data", well if the data you're protecting would be worth less than roughly $10,000 to an attacker, then back in 2009 it was probably just secure enough. And in 2014, if your data is worth encrypting at all, the answer is no.
If you have Java 6 available, everything you need is available. Check out this question and look at the accepted answer for a code sample. Since you want to encrypt files, the iv that is generated should be prepended to the file you are writing the ciphertext to, so that it is available during the decryption.
You should not be keeping the passwords in any form other than salted hash digests.
You should then use the operating system permission system to make it such that the hashed password file is only readable by the user which validates passwords.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
JDK8 uses the SHA algorithm in its JavaKeyStore class.
From the sources, you see that during engineLoad - if a password is given - it generates a SHA MessageDigest based on the provided password. If I get the code correctly, the entries of the keystore are signed with the password in advance. The SHA-Password-MessageDigest is used to check integrity by comparing the stored hashes with the calculated ones - for each entry.
Since SHA is known to be unsafe in certain scenarios, this generates security findings by runtime scanners. Software that uses Java's KeyStore (e.g. Apache Kafka) might be impacted.
I was wondering how bad this security issue is in practice. What attack vectors would be possible?
I'd like to hear assessments of others.
No it is absolutely insecure. It is used whenever the Java KeyStore (.jks) is loaded with a password. It then calculates this poor mans MAC over the read data and then compares it with a stored stored password hash.
As it only calculates a SHA-1 over the contents, password and a static magic string "Mighty Aphrodite", it would terribly easy to simply perform e.g. a dictionary or rainbow table attacks. You can even speed this up significantly by simply calculating the data first and storing the intermediate hash value. So it is not insecure because it uses the broken SHA-1 hash so much - although that is also a concern - but because it makes it pretty easy to recover the used password. Using PBKDF2 with a high iteration count and a warning in case the security of the password is insufficient would have avoided this issue.
Current SHA-1 attacks still require precalculation and we may assume that the keystore contents are generally not precomputed by an adversary. Still, SHA-1 is broken w.r.t. collision resistance so the integrity of the file is not completely assured.
I don't see how length extension attacks will make it any worse since the entries are read before the password is used, so fortunately it should be OK against those. Replacing the password would however not be an issue at all, which may be used for a social attack (Have you used the wrong password "hi" to protect it? Maybe you should replace that password?).
Note that from Java 9 you should really be using a better key store than JKS (such as a PKCS#12 key store).
The JavaDoc specifically says that the intention of this is
To guard against tampering with the keystore
This all comes down to what your security goals are.
Since SHA is widely known to be unsafe
SHA is not "unsafe". That is a very over-simplified assessment. It is simply too fast to be useful for hashing passwords. It is perfectly "safe" for many other use-cases.
A keystore is not a password, obviously, so the security goals are different. A keystore is a local file. Usually, if a malicious user has physical access to your machine then the battle is already lost.
In this case, the hash is used more for integrity and authenticity than anything else. In which case, SHA is a fine choice.
I need to decrypt messages via RSA in order to send it over an unsecured channel, but I'm afraid of the Padding Oracle Attack. Therefore I already have asked the follwoing questions:
How to verify the integrity of RSA encrypted messages?
How to ensure message integrity for RSA ciphers by using javax.crypto.Cipher
Like suggested in the first question,
However, since you are using a high level cryptographic library, this is something you shouldn't have to worry about. The writers of that library should have taken care of it.
I shouldn't consider about. As far I know, the RSA implementation of PKCS#1 v1.5 is vulnerable to the Padding Oracale Attack whereby OAEP isn't (assumed it's implemented correctly)
Hence I want to know which padding implementation is used by javax.crypt.Cipher by Java 7
It depends on the chosen or default provider which padding is actually used when you instantiate a Cipher without fully qualifying it like:
Cipher.getInstance("RSA")
Doing so is a bad practice, because if you switch Java implementations, there might be different defaults and suddenly, you won't be compatible with the old ciphertexts anymore. Always fully qualify the cipher.
As I said before, the default will probably (there are many providers, one can't be sure) be PKCS#1 v1.5 padding. If you need another, you would have to specify it. If you want to use OAEP, here is a fully qualified cipher string from here:
Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");
That's not a good advice given in the first link to the cryptography site. You should never rely on the defaults of cryptographic libraries cryptographic algorithms. There are quite a few reasons for this:
Different implementations, different defaults (there are no requirements for cryptography providers concerning defaults, although most will copy the Oracle/Sun defaults);
What's secure now may not be considered secure tomorrow, and because for backwards compatibility, you can never change the default;
It's unclear to anybody reading your software what the default is (you could document it, but in that case you might as well write it out).
The SunJCEProvider provided by Oracle defaults to PKCS#1 padding ("PKCS1Padding") for historical reasons (see reason #2 above). This is not well documented.
At that time that default was set you basically had just the insecure textbook RSA ("NoPadding") and the PKCS#1 v1.5 version ("PKCS1Padding" or RSAES-PKCS1-v1_5 in the PKCS#1 v2.1 standard). At that time RSAES-PKCS1-v1_5 was definitely the more secure choice. Changing the default now to OAEP would break every RSA implementation out there that uses the default.
The advice of otus (in the first link within this answer) is be better suited to protocol implementations in libraries than to cryptographic algorithms. In the end you should be able to defend the security of the choices made, whatever you choose.
The default for bouncy-castle when you just specify RSA is RSA/NONE/NOPADDING
This is the same result as RSA/ECB/NOPADDING as well.
I've encrypted a file using Bouncy Castle API. I've successfully decrypted that file using the same API.
However I cannot decrypt the file using PGP command line
No error messages are shown but the decrypted file is not being generated:
C:\pgp-cli>pgp arquivo-cripto-cast5-bin.pgp
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Export of this software may be restricted by the U.S. government.
File is encrypted. Secret key is required to read it.
Key for user ID: contine
2048-bit RSA key, Key ID 0x150AAE5B, created 2015/03/26
Key can sign.
Could it be a compatibility issue?
PGP 6.5.8 is horribly outdated, a lot changed in cryptography since then. There is a bunch of ways to introduce incompatibilities with this old PGP version, and it's hard to tell what exactly is the problem. Since that old version, new ciphers (both symmetric and assymetric), hashing and I think even compression algorithms have been introduced.
If you do not want to buy a newer version, consider using GnuPG which is free and mostly even compatible with PGP's arguments (and probably has much broader usage than the good old PGP, which is owned by Symantec at the moment). A readily built GnuPG package for Windows is available on GPG4Win.
I'm creating a web service that stores a list of users with their public keys online, as well as encrypted messages. My end goal was end-to-end encryption.
I initially thought this would be pretty easy -- "Oh, OpenSSL and RSA private/public key asymmetric encryption is great." False. RSA will only encrypt a tiny bit of data, presumably to pass a regular, symmetric key back and forth.
Okay, so I tried to find solutions online. Most of them either ended without a functioning example or pointed at using the command line, all of which seemed excessive and incomplete.
Is there a way to use end-to-end encryption on data with asymmetric keys, or is it all a personal pipe dream? OpenSSL in PHP has a way to do this already, and it's kludgy but it works.
Is there some method I'm missing here?
The common way to encrypt larger amount of data with a asymmetric keys (eg. RSA) is by use of hybrid encryption. In hybrid encryption you mix symmetric and asymmetric encryption. First you generated a random symmetric key, that is used to encrypt the data. Then you encrypt the symmetric key with the asymmetric key. The encrypted data + the encrypted random key are then put together and makes up the full encrypted data.
The openssl_seal() in PHP you refer to, uses hybrid encryption where the symmetric algorithm is RC4. How data is encoded and put together in the encrypted files have been defined by the openssl implementation, and might not necessarily be the way you would want to do it. PGP, as an other example of hybrid encryption, uses it's own way of packing the data.
In any case, hybrid encryption is not something you get out of the box in java, and you typically need to implement each of the encryption + packaging steps yourself, or use one of the libraries that implements there version of this. An example of doing it yourself is this Java code I found that can decrypt messages encrypted with the above mentioned openssl_seal().
An example of using a library for hybrid encryption, could be using the PGP support in Bouncy Castle.
Ebbe's answer is very good, however this question was highly ranked in Google in my attempt to try and find a decent hybrid encryption library (Bouncy Castle's documentation is non-existent and not straight-forward, and GnuPG for Java relies on the OS and is not fully tested). So I thought I'd add on to Ebbe's answer for the weary traveller.
If you can use them, JWTs (JavaScript Web Tokens) could be handy for this. It's also an IETF Standard. There are two different types:
JWS, which is a signed JWT. Plain-text message, but you can verify its authenticity. Which has its own IETF Standard
JWE, which is an encrypted JWT. Which also has its own IETF Standard
Support for JWEs are unfortunately a bit poor at this point in time. However this should hopefully improve. At this point in time (2017-04-11), the only Java JWT library that supports JWEs is BitBucket's Jose4j.
I'm not really sure what you're trying to en- and decrypt, but GnuPG for Java might be a good choice.
It supports public and private keys and can en- and decrypt bigger files and data.
I have just watched a crypto 101 talk which said if you are typing the letters "AES" into your code, you're doing it wrong! The solution was to "just use GPG".
If you are storing your data on the cloud, all readers and writers need to know the key. If the key is a public private key, that's just a slow key but not a more secure key than just having a good password?
What standard alternatives are there to GPG that properly encrypt data at rest but use a shared secret instead of public keys?
I use Java, and would like to use a library, but want interchange with other platforms.
The solution is wrong in terms - you don't use "GPG" but OpenPGP.
Indeed for encryption using shared secrets (passphrases and alike) OpenPGP is optimal, as it supports multiple methods at the same time and includes compression.
The alternative would be to use CMS encryption with keypairs derived (in some predetermined way) from the shared secret. However such scheme is not standard.
I can remember also XML encryption that supports encryption with symmetric keys, but it has certain security flaws.
So OpenPGP is probably the best way to go.
Regarding compatibility - OpenPGP-compliant library should create packets that can be later processed by any other OpenPGP-compliant library or application. Unfortunately OpenPGP implementation in popular BouncyCastle library sometimes produces not compliant packets - we came across its issues several times when packets created with BouncyCastle could not be processed by GnuPG or our SecureBlackbox due to issues in the packet created.