I'm trying to make a decryption of a string in JAVA encrypted in Delphi with DCPcrypt. DCPcrypt uses a Hash algorithms and a custom key for initialization, then an encryption algorithm. Is it possible to decrypt it in JAVA using Java ™ Cryptography Architecture or another JAVA cryptography library? If not have you any idea what libraries combination in JAVA and Delphi allows to have the same results for decryption and encryption of any string ?
Try Chilkat Android and Chilkat Delphi: https://www.chilkatsoft.com
The one thing you have to do to get the Chilkat examples for Delphi and Android to produce the exact same encrypted strings is change the padding scheme to 4. Out of the box, the Android example has a padding scheme of 0, and that results in different trailing bytes. It's worth noting that the Delphi and Java examples have no issues at all.
Now that you've got the answer, and having spent a week on this, I can tell you what doesn't work.
Trying to mix 3DES messages, whether using SHA1 or MD5 on the password, between JCE+JCA and Delphi Encryption Compendium is not going to work. For starters, DEC MD5 is crap. You're better off using the Indy MD5 hash class. It's too bad the version of Indy that comes with XE doesn't include encryption, because their MD5 hash class is flawless and easy to use.
Lockbox didn't want to play nice with Java encryption. In that case it may be that I was so burned out on DEC that I had lost all patience. Again, I spent an entire week, all day and into the night trying to get the various parts to work. I never got to DCP. The next thing I tried was Chilkat.
With Chilkat, I downloaded the trials and installed them, ran the examples, and it all worked straight out of the box. Done.
Related
Recently I have some files which are piped from a remote connection as encrypted files and loaded onto an Android app which are decrypted on runtime. I have found that the exact same decryption code is available here along with the keys. Unfortunately it is in Java and hence one that I am not familiar with, I have no experience with encryption. The link for the module is here
https://github.com/fukata/AES-256-CBC-Example/blob/master/java/src/AESUtil.java
The encrypted example is here
https://zerobin.net/?c5fd41740c9301ef#iNG7oNExRZwK4hBEKP7ZORDBj1fcPZxyjLQZeAihGZ8=
I have been trying to decrypt it by using AES utilities found in VB.NET but unfortunately it doesn't seem to work. So my question is are AES encryption methods different from language to language? IE is something encoded by AES in Java different from one in VB.NET - which would mean i would have to translate the java code directly?
Thanks!
You must use the bit-for-bit identical key and initialization vector as well as the same block chaining mode, but other than that, the language in which an encryption algorithm is written does not matter.
"Is AES Encryption different from language to language?" no.
aes is only an algorithm (computation instruction). aes has maybe a reference-implementation, but it has no "one only correct standardized implementation".
the implementation of aes may be a little bit different in any language. for example in vb.net you would typically use "Byte" as type for an unsigned number in an aes-implementation. however java has no unsigned datatypes, so you have to convert the bytes which are representing negative numbers to avoid encoding-problems. but you do not change the real encryption-algorithm. so you can encrypt your data with an aes-implementation in an arbitrary language and decrypt it with an aes-implementation which is written in another language. if this does not work one of the implementations is flawed.
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'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'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.
I have an Android application, which uses javax.crypto to encrypt some text data in files. Encryption implementation is similar to this. The application works fine with the encrypted data it previously created.
Now, I almost ported my Android application to desktop (JFace/SWT). I'm using the same encryption implementation for the ported application, as it does not depend on any Android-specific API. The ported application works fine with encrypted data it created.
The problem is that desktop application cannot decrypt data, which was saved with Android application. The Android application fails to decrypt data, which was saved with desktop application as well. I double checked bytes streams of plain data and password to encrypt on both platforms. They are the same, so there are no problems with text encoding or so. But encryption routine return different encrypted results on different platforms even input data is byte-to-byte identical.
Does Java crypto API guarantees the same operation on different platforms? Should an encryption provider (AES/128bit in my case) work the same way on Android, Linux and Windows? Is there a way to tune javax.crypto to get interoperability on different platforms?
AES-128 should work the same on both systems. In theory.
In practice there are a lot of details that need to be the same on both systems.
are you using the same padding at both sides?
are you using the same mode (CBC, CTR, ECB) at both sides?
do you have exactly the same password at both sides?
do you have the same IV/Nonce at both sides?
do you have the same key derivation method on both sides?
Check any defaults on both systems. If the defaults don't match then you will need to set one side or the other explicitly.
It is a mistake to depend on a cryptographically-random number generator generating the same random numbers on different platforms. Normally, the cryptographic random salt used in a key-derivation algorithm has to be communicated from sender to receiver. It might be communicated as a secret, but it does need to be communicated. The "master password" is the main secret, of course.
One way these salts are often communicated is as a prefix on the ciphertext. That makes the ciphertext longer than the plaintext, but I don't think that matters in your sample technique.
Also, for a full-up encrypted-message exchange, other parameters of the encryption need to be communicated to the decrypter. You can wire those into your implementations, as you've done here, but depending on reproducibility seems too brittle. It is of course something an attacker can replicate, of course, so it is not part of your secret.
You might want to rethink the key-generation algorithm setup to be something more robust.
Afterthought: What is happening in the current approach is a cryptographically-useful RNG is being used in a way where all the randomness has been removed! The recommendation to check out PBKDF2 and key-derivation generally is a good one.
You'd have to show us some code. One frequent beginner mistake is to store the encrypted data in a String rather than the byte[] it came in. String isn't a container for binary data. This technique can fail in many ways including default charade differences.