I'm working on a Groovy application that has to provide users with a link containing encrypted query parameters. Currently we use the AES encryption algorithm with the same IV used for all links. We know this is bad (hence the reason we want to switch), but the reason this was done was to limit the size of the query parameters (including a base64 encoded 16 byte initialization vector with each query parameter makes the links very long). We'd like to switch to a non deterministic algorithm so that we have the required randomness in the query data but don't have to store the IV in the query parameters.
Since we're working with Groovy we can use anything from Java. Having not done much encryption work though I'm not sure which algorithm to start looking into. Ideally we'd want one that's available in Java SE or as a freely usable Java library. Also any links with details on how to implement these algorithms is highly appreciated.
The aim is to not use the same initialization vector twice. If you have something unique in the request that the server know when decrypting, you might use that as the initialization vector.
Otherwise, you could simply use a counter as the initialization vector. Keep a central counter that you increase each time you encrypt something, and put that counter in front of the encrypted data. Then expand this counter to a 16 byte initialization vector.
Related
hello I am new to java and i want to develop a simple login application where i have to store values in db. I have read many examples for encryption and decryption but i cant understand(may be because of complex english words) what is algorithm,key, padding and why we have to use getBytes(). Can you explain in detail with examples in simple english. Which algorithm,padding is best useful for encryption and decryption.Is key a predefined fixed word or can we set our own key. Code will be much useful.
Im kinda newbie on the subject so id just recommend hashing and salting the passwords, i cannot offer much more insight, but i found this video which i found to be quite extensive and interesting on the subject, and iirc he even shows some code samples and examples, i recommend starting from there and come back with doubts from that!
The general gist of things is getting the original password string, and generate a random string with it, concatenating both, then hashing the combined form of those and storing the hashed form of both and the random string, then, when that person is going to login, you apply the same salt to the password inserted and compare it to the hashed form in your database.
This has advantages over standard hashing because the random string is unique per user, meaning all hashes, even from the same passwords, will be different, while in normal hashing, youd get the same hash for the same passwords, and thus, it would be easier to crack some if many users had the same password, which cant be done in this case, since every hash key is different.
So remember, generate random string, concat it, hash the concatted string, store the hash and the random string into the db, and compare on login.
I am actually nicely surprised, someone asked before doing it wrong way.
However what are you asking is quite broad for a single answer. I'd advice to take at least some basic course on cryptography (I'd recoment the Coursera. Even if you don't finish your course, you will get pretty good basics what and why you shoud or should not do.
simple login application where i have to store values in db
If the values you mean user passwords, then use slow salted hash, please read https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
If you want to encrypt some values reversibly, there are plenty examples around, though not all are secure,
Code will be much useful
you may check
https://gusto77.wordpress.com/2017/10/30/encryption-reference-project/
what is algorithm,key, padding and why we have to use getBytes().
I will start with the bytes. Encryption works with byte arrays. So for any text you need to convert your data, keys, passwords,.. to byte arrays. As well the encrypted data are byte arrays.
For the algorithm, padding,.. I really advice you to learn about it a little more yourself.
There are ciphers (algorithm) which are considered secure today, it is more important that you use them properly.
Just for an example, commonly used is AES/CBC/PKCS5Padding
AES - cipher (encryption algorithm)
CBC - mode of operation
PKCS5Padding - padding to fit data into required block length
.Is key a predefined fixed word or can we set our own key.
Key is your secret value, you need the same key to decrypt encrypted data, but the key is yours, the best if it's random
I'm trying to write a simple password manager in java. I would like to encrypt the file with the stored passwords using AES 256 bit encryption. In addition I would like the user to be able to decrypt the file with a password. When reading other posts online almost all of them stress that it is not secure to simply use a password as a key, they mention using random salts to add security. But I do not understand how I can use random salts when generating the key. If I create the key from the user's password and a random salt then when they try to decrypt their file how will I know what the salt was? This has me completely confused.
Currently I run their password through several different hashes using a constant salt at each step. Is this sufficiently secure or I am I missing something? Any help on how to securely generate a key from a password would be greatly appreciated! Thanks in advance.
Remember that a salt isn't a secret. You can just append it to the encrypted data. The point of the salt is to prevent somebody from using a pre-computed dictionary of common pieces of data encrypted with common passwords as a way into "cracking" the encrypted file.
By making sure that the salt is random and combining it with the password, you remove the possibility of a dictionary attack because there's (effectively) no chance that a hacker will have a database of data pre-encrypted with your "salt+password". (As a starter, see this page, from one of my tutorials, on salts in password-based encryption.)
You also (effectively) eliminate the problem of collisions: where using the same password on two files may give an attacker a clue to the content if the same block of data occurring in both files looks the same in the encrypted version.
You still usually need to take other precautions, though, simply because a typical password doesn't usually contain much entropy. For example, 8 perfectly random lower case letters will generate about 40 bits of entropy; 8 lower case letters obeying typical patterns of English will generate about 20 bits of entropy. In other words, of the 2^256 possible keys, in reality typical users will be choosing among some small fraction in the range 2^20-2^40. In the case of a savvy user, the situation gets a little better, but you will be very unlikely to get close to 256 bits of entropy. (Consider that in a "pass phrase", there'll be about 2.5-3 bits of entropy per character, so a 30-character pass phrase gives you about 75 bits of entropy-- and let's be honest, how many people use anything like a 30 character password?; 8 perfectly random characters using the 'full' range of printable ASCII will give you a little under 64 bits.)
One way of alleviating this situation a little is to transform the password (with salt appended) using a computationally complex one-way function so that it will take a hacker a little longer to try each key that they want to guess. Again, see this page for more details.
To give you a rough idea of the pitfalls of password-based encryption of files, you may also want to have a look at the Arcmexer library I wrote a couple of years ago, which includes a method named isProbablyCorrectPassword(). Combined with a dictionary/algorithm for generating candidate passwords, you can use it to gauge the effectiveness of the above methods (since ZIP file encryption uses a combination of these techniques).
Use this library: http://www.jcraft.com/jsch/
There's a good AES example ere:
http://www.jcraft.com/jsch/examples/AES.java.html
A lot of big names use this package, Maven, Eclipse, etc.
Based on a previous question, I am using a sequential integer as a record ID in my database. I want to obfuscate the integer IDs using Skip32. I found a Java implementation but I am uncertain of how to initialize it using the standard JCE APIs. I need to encrypt an integer and decrypt it as necessary. Can anyone show me an example of this?
The code you found belongs to the Cryptix project. You need not just this one file, but you should take the whole package. Take the JCE package, install it as a provider. Then you should be able to use
Cipher c = Cipher.getInstance("SKIPJACK");
But actually, instead of using an unsupported library like Cryptix, using the BouncyCastle library (or parts thereof) might be more recommendable. They have lots of documentation, and a SkipJack-implementation, too.
I'm not sure why you would need to use Skipjack instead of any cipher which comes with your JRE, though - just for the smaller block size?
If I understand right, Skip32 is a separate cipher (working on 4-byte blocks), just build by similar principles like Skipjack (which works on 8-byte blocks). I didn't find any specification of it, only some C and Perl source code, so I doubt there will be some Java implementation available. Have a look at Format-preserving encryption on Wikipedia, or Can you create a strong blockcipher with small blocksize, given a strong blockcipher of conventional blocksize? on Cryptography Stack Exchange, which show other ways of building a small-block cipher from a larger one.
You might find this blog post on secure permutations with block ciphers useful in figuring out how to implement it. Any block cipher with a sufficiently short block size will suffice.
I implemented Diffie–Hellman key exchange in Java with some large groups from RFC 3526. My output is a fairly large array of bytes. Is it safe to use the first 448 bits (56 bytes) of the output for a blowfish key? Should I transform the bytes in any way, or pick any specific bytes for the key?
From a theoretical point of view, no, it is not safe. Not that I could pinpoint an actual attack; but the output of a Diffie-Hellman key exchange is an element of a group consisting in q elements and offering sqrt(q) security at most. Truncating parts of the encoding of that element does not look like a good idea...
The "proper" way is to use a one-way key derivation function. In simple words, process the Diffie-Hellman output with a good hash function such as SHA-256 and use the hash result as key. Hashing time will be negligible with regards to the Diffie-Hellman step. Java already includes fine implementations of SHA-256 and SHA-512, and if you are after compatibility with very old Java implementations (e.g. the Microsoft JVM which was coming with Internet Explorer 5.5) then you can use an independent Java implementation of SHA-2 such as the one in sphlib. Or possibly reimplement it from the spec (that's not hard): FIPS 180-3 (a PDF file).
If you need more than 128 bits for your key then this means that you are a time-traveler from year 2050 or so; 128 bits are (much) more than enough to protect you for the time being, assuming that you use a proper symmetric encryption scheme.
Speaking of which: Blowfish is not really recommended anymore. It has 64-bit blocks, which implies trouble when the encrypted data length reaches a few gigabytes, a size which is not that big nowadays. You would be better off using a 128-bit block cipher such as the AES. Also, in any serious symmetric encryption system you will need a keyed integrity check. This can be done with a MAC (Message Authentication Code) such as HMAC, itself built over a hash function (then again, easy to implement, and there is a Java implementation in sphlib). Or, even better, use the AES in a combined encryption/MAC mode which will handle the tricky details for you (because using a block cipher properly is not easy); lookup CWC and GCM (both are patent-free; the latter has been approved by NIST).
The solution that you propose depends on whether the most significant bits of a Diffie-Hellman exchange are hard core. There are some small results known that show that the most significant bits are unpredictable, but I'm not aware of a paper that is strong enough to show that your approach is correct.
However, there are several proposals for a key derivation from Diffie-Hellman keys.
E.g. a nice paper is NIST SP 800-135. So far this is only a draft and can be found here. However, it reviews some existing standards. Of course, using a standard is always preferable to develop it yourself.
While Thomas Pornin's proposal looks reasonable it is nonetheless an ad hoc solution. And to be on the safe side you should probably not use it. Rather I'd use something that has been analyzed (e.g. the key derivation scheme use in TLS version 1.2).
I want to write a very simple implementation of an onion router in Java (but including chaum mixes) - a lot of the public / private key encryption seems pretty straightforward, but struggling to understand how the last router would know that the final onionskin has been 'peeled'.
I was thinking of having some sort of checksum also encoded, so that each router tries a decryption with their private key, and if the checksum works - forwards the newly peeled onion to the next router.
Only this way, (assuming that some bit of the checksum are stripped every time a successful decryption occurs) there will be a way (looking at the checksum) to estimate how close it is to decryption -- this this a major vulnerability ? is the checksum methodology an appropriate simplification?
Irrespective of the problem you mention, it's generally good practice to include some integrity check whenever you encrypt/decrypt data. However, checksums aren't really suitable for this. Have a look at Secure Hash algorithms such as SHA-256 (there are implementations built into the standard Java cryptography framework).
Now, coming back to your original question... To each node of the onion, you're going to pass an encrypted "packet", but that packet won't just include the actual data to pass on-- it'll include details of the next node, your hash code, and whatever else... including whatever flag/indication to say whether the next "node" is an onion router or the actual end host. Indeed the data for the last node will have to have some special information, namely the details of the actual end host to communicate with. In other words, the last node knows the onion has been peeled because you encode this fact in the data it ends up receiving.
Or at least, I think that's how I'd do it... ;-)
N.B. The encryption per se isn't that complicated I don't think, but there may be one or two subtleties to be careful of. For example, in a normal single client-server conversation, one subtlety you have to be careful of is to never encrypt the same block of data twice with the same key (or at least, that's what it boils down to-- research "block modes" and "initialisation vectors" if you're not familiar with this concept). In a single client-server conversation the client and server can dictate parts of the initialisation vector. In an onion router, some other solution will have to be found (at worst, using strongly-generated random numbers generated by the client alone, I suppose).
You could hide the number of checksums by storing them in a cyclic array, whose initial offset is chosen at random when the onion in constructed. Equivalently, you could cyclically shift that array after every decryption.