Why is Cryptomator written in Java? Isn't Java insecure?

About Java

Yes, JRE installations have indeed opened certain doors for malware. That is why you should not use the Java browser plugin, for example. That said, the Java programming language itself isn’t more vulnerable than any other language:

How is Cryptomator different?

Even though huge parts of Cryptomator are written in Java, you do not need you to install a Java Runtime Environment (JRE) because the relevant parts are bundled with the installer.

This means that, other than a system-wide JRE installation, malware (or third party applications) are unable to start a Java process with the components bundled within Cryptomator because there is no executable Java binary included.

Benefits of using Java

The Java platform is one of the most widespread technologies and thus very well tested and mature. It is used by the biggest tech companies around the world who build products around it that need to be highly available and robust.

As Java is a managed language, it has a higher isolation level than low-level languages that can mess up memory management and leak sensitive information and are susceptible to memory tampering.

These properties make the Cryptomator source code easier to test and audit by professionals as certain types of vulnerabilities just don’t apply.

  • Is encryption part done using OpenSSL? Or using a Java library?

(See below for an answer)

  • Any plan to rewrite Cryptomator in Go?

Java libraries are not as vetted as Go crypto libraries. Java is a strange choice for a security product.

—————————————-

Edit: The encryption is done in a Cryptomator library called CryptoLib written in Java:

GitHub - cryptomator/cryptolib: Cryptomator Crypto Library

Some parts seem to be based on Java JCE library and some parts written by Cryptomator developers, for example, RFC2898.

CryptoLib has been audited and separated from GUI part, which is good.

No. Oddly specific question. Why should we?

Is that so?

Besides already bringing all required cryptographic primitives on all supported platforms, Java is intrinsically immune against virtually any memory safety issues, which accounts for a majority of vulnerabilities.

But please enlighten us!

Go would have been a good choice for cryptomator. You could have gotten a modern AEAD (probably a ChaPoly cipher) from Secret Box from Go crypto library (Go translation from libsodium and NACL) that is practically bullet proof. You basically let Bernstein and Google perform and maintain encryption for you, and instead focus on UI.

A lot of good developers are working on and using Go crypto. Chances that a bug or supply chain attack will go unnoticed are pretty low.

Java Cryptography Extension and Oracle are frankly strange. Nobody is using it, and bugs and attacks can go unnoticed. It’s not a well regarded source among crypto people.

Sorry, it was an honest (and in my view, good) comment!

Good name dropping, but still “practically bullet proof” is the kind of snakeoil advertisment we try to avoid. So may I ask again you to substantiate your claims? Please.

I’m not sure if you’re knowingly oversimplifying oder actually naive. That is not how applied cryptography works. Just because some lib adds a new and possibly “better” cipher doesn’t magically improve the app that uses it.

No doubt!

Did I mention that I would like to hear why?

Come on. Google some market share stats. Basically every Java app, device, application server, … uses it. What do you think Java’s TLS ciphersuites are based on?

Sure thing, as in any lib, but certainly not due to missing spread (especially when compared to Go).

It is of course debatable what makes a comment a “good comment”. Since I am honestly interested in why you deem Go so much superior that you would even ditch thousands of commits merely for a language, I would consider a comment “good” if it was backed by facts. That’s all I’m asking for.

3 Likes