Blowfish compatibility with other blowfish implementations

I just went without encryption for now — as it turns out it was unnecessary for my specific application.

This could be a great JUCE demo — I’m sure people will be using JUCE apps alongside web apps more and more. I would love to see an “official” working implementation of encryption in Node.js and decryption in JUCE.

+1 Would be good to know which mode is used, and even better, an example with openssl encryption and JUCE decryption.

1 Like

I want to use openssl_encrypt on our server too, so knowing which cipher mode the BlowFish algorithm uses is quite essential. @jules should know :wink:

1 Like

I couldn’t tell you for sure, it’s years since I wrote it, but I assume it’s the most common one: CBC

Looking at the code I’d say the mode is ECB. There is no feedback of the previous cipher into the next block encryption.

I’m actually quite sure it’s not the most common one. Or some of the other settings differ with common defaults. If I remember correctly I tried both ECB and CBC and neither worked.

In the end I ended up using cryptopp instead of juce’s crypto module, and I’ve heard from more parties they struggled with getting BlowFish to work. Sounds like perhaps it warrants another review?

We decided to not use the JUCE implementation. Even if we could get it to work, ECB is too insecure to be useful.

See: TwoFish and ThreeFish

Cheers,

Rail

reFX wrote:
We decided to not use the JUCE implementation. Even if we could get it to work, ECB is too insecure to be useful.

I know this is an old thread.
But I am curious: how is the JUCE Blowfish too insecure? I was planning on using it myself…
I am a newbie on encryption. Sorry, if this question is too obvious :slight_smile:

For a quick visual example:

Thanks, I see. Interesting.
Is this picture the “real” thing? Or just a visualisation?

That’s a real example of what it looks like to use Blowfish with only EBC algorithm. If you used the same input image, you would get the same output.

It’s really quite unusable. It’s very unsafe. You will find plenty of better encryption/decryption algorithms online then using JUCEs Blowfish implementation.

Here is a header-file only implementation of both (EBC and CBC). You should use the CBC methods:

https://defuse.ca/blowfish.htm

Sorry to reanimate this. The Blowfish implementation in JUCE does not play nicely with OpenSSL / Cryptopp because it reads the data in host endian mode. This probably also means that you cannot encode with JUCE on BigEndian and decode on LittleEndian. Apparently other implementations have had the same issue before (see https://stackoverflow.com/questions/11422497/whats-the-difference-between-blowfish-and-blowfish-compat).

I was able to make it match cryptopp and openssl using the following patch.

diff --git a/modules/juce_cryptography/encryption/juce_BlowFish.cpp b/modules/juce_cryptography/encryption/juce_BlowFish.cpp
index fb4fa22e5..c585392b5 100644
--- a/modules/juce_cryptography/encryption/juce_BlowFish.cpp
+++ b/modules/juce_cryptography/encryption/juce_BlowFish.cpp
@@ -330,7 +330,13 @@ bool BlowFish::apply (void* data, size_t size, void (BlowFish::*op) (uint32&, ui
    auto* ptr = reinterpret_cast<AlignedAccessHelper*> (data);

    for (size_t i = 0; i < n; ++i)
-        (this->*op) (ptr[i].data[0], ptr[i].data[1]);
+    {
+        uint32 a = ByteOrder::swapIfLittleEndian(ptr[i].data[0]);
+        uint32 b = ByteOrder::swapIfLittleEndian(ptr[i].data[1]);
+        (this->*op) (a, b);
+        ptr[i].data[0] = ByteOrder::swapIfLittleEndian(a);
+        ptr[i].data[1] = ByteOrder::swapIfLittleEndian(b);
+    }

    return true;
}
1 Like

Wow, I am glad you shared this @harrycodex. Since the juce team doesn’t respond to pull requests, I hope this gets some attention from them on the forum and gets merged ASAP!

Merging a change like this is difficult, because it would be backwards incompatible with things encrypted with previous versions. I’m not sure how I would choose to fix that, constructor option or different class name maybe.

1 Like

That would mean that is not even blowfish anymore. It should be renamed to something else and a real blowfish algo should be implemented.

1 Like

To be fair the function that just takes 2 uint32_ts is the blowfish algorithm as far as I can tell. It’s not totally clear to me where the specification that those uin32_ts should be read from the buffer as big endian comes from, but I’m sure it is somewhere.

There are several that are open-source. I don’t know if they’re single-header implementations, though. And I think the only official ones are the openssl and the bcrypt implementations.

I personally think that stuff encrypted with the old juce::BlowFish implementation would need to be re-encrypted with the new version, if the new version is actually correct.

Did anyone get blowfish working with Juce that was compatible with AWS?

Hmmm, interesting.
We’ve been using the BlowFish class as (one) part of our copy-protection / software activation system for years, and I have nothing much to add to this conversation apart from this:
I tend to agree 100% with @harrycodex above in that this is a very critical piece of code compatibility-wise: if something is changed to the semantics of this class, it should be done in a very careful and clearly visible way, by adding something new, instead of just changing the existing internal implementation, otherwise it could have very bad effects for existing commercial software out there.

1 Like