From googling I found Jasypt, I'm wondering is it reliable? Anyone know about it?
I have come across it in my occupation and found it useful for verifying encryption algorithms from another source. I can't go into much detail of my verification processes but if you want to be able to encrypt data local to your PC then Jasypt is a great option. It abstracts a lot of crypto functionality and you can encrypt or decrypt data inside of 4 lines of code. However, if you want to encrypt traffic over a network then you may want to look into IPsec support. I also don't think you can configure the more granular settings in Jasypt like specifying a block or stream cipher type.
Related
I'm trying to make a game that will tie into website content, and users' accounts will be shared across the site multiple versions of the client.
The problem is that the password needs to be salt-hashed in PHP, and I need to be able to verify through Java, and I can't find any information on secure cryptos (like PBKDF2) and ensuring that the generation is identical between PHP and Java.
I've seen some info on using PBKDF2 on PHP, OR Hmac with SHA-1, but not combining them as is suggested in the name of Java's "PBKDF2WithHmacSHA1". I have a handle now on the individual hashing for PHP or Java.
How do I set up the methods to be able to generate a salt and hash on PHP, store it in MySQL and be able to verify passwords through Java's hashing functions?
Would prefer to stick with PBKDF2, if at all possible (unless someone can suggest an equivalent that would work better for cross-compatibility).
P.S. Not particularly sure whether this deserved to be here or on Crypto SE. I figured, since I was asking about specific languages, I'd try here first.
So, it turns out it wasn't as complicated as I was thinking it was. I found this question that said that PHP's equivalent to Java's PBKDF2WithHmacSha1 was the hash_pbkdf2 function with the sha1 algorithm. From there it was just a matter of transferring the salt and hash from the PHP to the Java. Here's how it ended up:
1) PHP: For this one, I just copied the guy's pbkdf2 function and generated the salt and hash like he did.
2) Java: All that needed to happen was a bit of a change in the bytecode conversion, and it worked just fine.
After that, all I needed to do was modify the Java code to fit into my server/client setup (including secondary session hashing), and work out a few more bugs surrounding more salt and hash encoding and decoding through network transmission, and it works perfectly now.
A slightly more detailed answer is available on that other question.
Try to consider using a pre-built user and password management like JBoss KeyCloak. It is based on standards like OAuth2 and OpenID Connect, and things like password reset, user registration and social login come for free. It includes connectors for Java and JavaScript. Apparently connectors for PHP are available as well.
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.
I'm making a project in Java and Python that includes sending an encrypted string from one to the other. I can get the languages to understand each other and fully de-crypt / encrypt strings. However I was talking to somebody and was told that I am not being totally secure. I am using AES encryption for the project. Part of the problem is that I am distributing the software and need to come up with an effective way and secure way of making sure both the server side know the IV and 'Secret Key'. Right now the same string will always encrypt to be the same result. If I could change those two factors they would be different, so 2 users with the same password won't have the same encrypted password. Please do keep in mind that the server only needs to manage one account.
I appreciate your responses, and thank you very much ahead of time!
Typically, you'd generate the IV randomly, and send it along with the encrypted message. The IV doesn't need to be secret--it just needs to be different for every message you send.
There are a wide variety of concerns to worry about when implementing crypto. Your block cipher mode matters, for instance--if you're using an IV you probably aren't using ECB, but that leaves quite a few other options open. Padding attacks and other subtle things are also a concern.
Generally, you don't want to implement crypto yourself if you can possibly avoid it. It's much too easy to get wrong, and usually quite important to get right. You may want to ask for more help on the Security StackExchange.
I'm looking for a secure symmetric-key encryption algorithm compatible with both JavaScript and Java.
I've tried implementing one but I had some encoding issues.
You don't want to encrypt with JavaScript, especially on the client-side where it is open to tampering, and has no cryptographically secure random number generator.
I've tried implementing one but I had some encoding issues.
You tried to write your own encryption algo? You've gone against everything that the security world hold dear. No. Actual tutorials that explain how encryption works are so scared that people are going to screw things up because they don't understand the math behind it, I've actually seen this in one of them:
If you don't understand encryption, things like, what "cryptographically secure pseudo random number generator" actually is, and common attacks on it, you shouldn't do that.
If you don't understand things like side-channel attacks, you shouldn't do it.
If you don't understand what's going on in crypto and have read at-least two books on it you have no business implementing it.
Crypto is not a magic black box, it's something that is very VERY easy to screw up, even without touching any bit of code in a packaged solution.
What should you do? Forget about JS encryption. I know, I've tried it myself. It's a waste of time. Learn from my mistakes.
Go get an SSL certificate, SSL is the best way for us to encrypt messages on the transport level from a server to a client. It's about as secure as you can get. If you face an advesary that can defeat SSL, trust me, your JS-based crypto is also compromised.
Once it's at the server where it's secure from being tampered with, encrypt it. Anything else is a really long way to waste your time.
Also, go read these books:
![This one is free][4]
[![This one is cash money][5]][5]
(source: [schneier.com](https://www.schneier.com/images/book-ce-150w.jpg))
Then when you understand them come back and scream at me about why I'm wrong and don't understand how much you need JS on the client to do crypto.
There is an excellent DES (and by extension 3DES) implementation in JS, which I use quite often. I'll put up the link Monday, when I'm at the office and have it ready. Results from this (after base64 encoding for the transport) work perfectly with .Net/Mono (builtin), Java (bulitin) and PHP (mcrypt).
Found the links, but both are dead: http://www.shopable.co.uk/des.html and http://www.netdealing.com. I have put it up on http://pastebin.com/KbRsWKJY
This page has CTR mode, which is available in Java. I would recommend keys of 128 bits or you might run into trouble regarding the Java export policies on larger key sizes.
Here is a page which uses some very usefull methods of encryption, including password encryption techniques and ciphres with integrity checks and authentication, although you may need the bouncy castle libraries on Java to match those all.
There are oodles of libraries for JavaScript, but character encoding issues will be present on any of them. So make sure you use the same encoding both on the JavaScript side as well as on the Java side. A quick look up assures me that JavaScript uses UTF-16 internally, but don't hang me up on that.
Finally, don't try this at home, the libraries are there, use them (especially if they mention tests and/or official test vectors).
Like the other answers said, if you don't have to encrypt with JavaScript, avoid it. However, there are some valid use cases to encrypting in JavaScript.
When you need to, I recommend this library: https://keybase.io/triplesec/.
It's more secure than DES, which another answer links to.
And by that i don't mean using HTTPS, but data encryption.
Is there a nice encryption method that i can use in PHP to encrypt the data and decrypt in Java?
Thanks in advance.
AES-256 is the same in both Java as PHP: the algorithm itself is naturally language agnostic, so you can just pick one. That said, if you were to use HTTPS, the data would be encrypted either way, so perhaps you're overcomplicating things? Is the data that important and privacy-sensitive?
HTTPS does data encryption. If you're planning to negotiate the encryption without any pre-shared keys then HTTPS is probably one of your best options. It's not trivial to get encryption done in a proper way, so it's usually best to leverage existing implementations.
If you are planning on using a shared key that the client and server each know about, then you do likely want to use AES. For the Java side see an example here. You'll have to search around for the PHP side. Be sure to follow all of the best practices if you're aiming for security.