Good. Usually, I would be against this like any other normal human being, but I can’t lie I’m gloating about this one.
We have had lots of similar cases where people not only blindly followed new regulations (for example, regarding cash) but also encouraged them — and the justification was always the same: "Why do you use cash? Are you hiding something? Cash is for criminals!" Now that the government is about to monitor their chats, they suddenly complain. Why are you bothered by chat control? Are you hiding anything? Encryption is for criminals!
I keep telling you what's what and you do nothing but gaslight me by trying to turn my words on me.
Language wars are silly and pointless. Someone tells me he/she uses language xyz, I basically don't care, do whatever works for you ,but God forbid you cross a .NET proponent. In case you haven't noticed, this is a post about Java. You mention Java, and the first thing that happens is a bunch of .NET maniacs popping up out of nowhere, telling you how Java copied this feature or how C# had that feature for years. What is this?
Looking into the negative comments is quite amusing. Not only do most of them contain technical inaccuracies, but of course, they also need to mention how great .NET supposedly has been from the beginning and how Java supposedly copied everything.
Let's take a stroll down memory lane. First of all, .NET literally started as a Java copy. On top of it, a non-cross-platform one for almost two decades! After having shamed Linux for so long Microsoft finally started porting .NET to other platforms in a non-backward compatible way. A lot of .NET proponents will tell you porting from legacy .NET to .NET Core (which was renamed once again to .NET) would be a quick fix, but it isn't. For example, the shop I used to work in had some important cryptographic libraries which were very painful to port. And then, there's .NET's simplistic garbage collector, which can be quite annoying because it tries to be a one-fit-all solution that basically cannot be tweaked at all, often resulting in unresolvable latency problems. There’s a lot of other stuff, like its ghetto-like ecosystem and the insane fragmentation of GUI libraries.
I also don't get the C# praise. Over the years, it has become quite the bloated language. It feels like Microsoft tries to implement every feature possible without realizing that an enterprise language is supposed to be streamlined. Async/await? Very ugly, very annoying. Java has solved this a lot better with virtual threads and structured concurrency.
I could go on, but these "language wars" are silly and pointless. Both platforms have their pros and cons. Besides, I have a lot of bad things to say about the JVM as well, but it's nice to see Valhalla finally beocming reality. Too late for me personally though.
Language design isn't just about adding every possible feature. For example, someone mentioned operator overloading. As someone who has written a lot of Scala, I think operator overloading would be a very bad feature for an enterprise language like Java which needs to be consistent above all else.
I never understood the obsession some people have with the C# vs Java debate anyway. Generally, both languages are very good at what they do, each having its own set of advantages and disadvantages. Regardless, a developer can pick up the other language with basically no effort.
> I cannot understand why Jetbrains keep the VM settings as constrained as they do. It's a big difference.
A lot of the things JetBrains does are questionable, particularly the way they write UI applications. One would expect from a company that spawned a widely used JVM language and a JVM IDE that they would know how to write responsive Java UIs, but apparently, they don't. They are doing some really weird stuff like mixing up Skia with Swing, it’s just a big mess. The worst part is that most people will end up thinking Java is the issue. Ironically, Microsoft has done the same to Visual Studio which is incredibly sluggish these days.
Lots and lots of smattering around here. If anything, this is a secure boot flaw (and partially TPM), but that is a separate conversation. Also, it's been known for years that TPM based encryption should always be protected with a PIN for truly sensitive data:
https://learn.microsoft.com/en-us/windows/security/operating...
The author claims to be able to bypass TPM + PIN protection, but I seriously doubt it because that would require breaking or exploiting the TPM itself. Perhaps the author was referring to existing fTPM flaws but even then, brute-forcing the PIN would still be required because on BitLocker, the wrapped VMEK depends on the PIN, which brings me to the "backdoor" topic.
As I have already mentioned, exploits have been found in AMD fTPMs in the past (https://arxiv.org/abs/2304.14717). This flaw is particularly severe on Linux/cryptenroll because the TPM returns the actual FVEK, unlike BitLocker, where the VMEK itself depends on the PIN. This cryptenroll flaw has been known for years and remains unfixed on cryptenroll (https://github.com/systemd/systemd/pull/27502). Yet, I see no one yelling and crying "backdoor", or accusing Lennart of being compromised. Cryptography, especially when combined with hardware security, is inherently not easy — and people make mistakes.
No. Technically, TPMs can store secrets (limited due to little nvram), but no FDE implementation as far as I'm aware does this. TPMs wrap/encrypt the key and return an encrypted blob which will be stored in the header which will be decrypted upon request. The actual KEK is never stored on the TPM.
> Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source implementations of FIDO2 and open-hardware ones too.
Not only do they do the same thing, they often use the same cheap chips. I don't see the benefit in using a separate device when you can have one SoC because there are too many downsides. Not only are dedicated devices vulnerable to sniffing and fault injection attacks, the extraction of secrets is actually feasible with the right kind of equipment. SoC solutions make this impossible (manufacturing levels are simply too small). Apple, Google, and Intel (Panther Lake) have solved this the right way. Open Source security can and should be shifted to PIN dependent key enrollment to protect against backdoored or flawed secure elements.
> Majority of hard disk encryption done in the HDD/SSD controller is 100 times more crap than BitLocker itself. It's littered with bugs and security vulns. Anybody using it is insane.
Oversimplified and not accurate. Some manufacturers had flawed implementations, others did not. Also, that was a long time ago. There are advantages to hardware encryption. It preserves performance and mitigates other vectors like cold-boot attacks without having to encrypt RAM, which also comes with a performance penalty. By the way, both software and hardware-based encryption can be combined. Cryptsetup on Linux actually offers this, and before you ask, the keys are split. If one is compromised, the other remains secure.
TPMs are a nice idea, but there are a few problems:
- The KEK should also depend on the PIN. Cryptpentroll does not do this at all and Bitlocker limits the PIN to 20 characters.
- There are various manufacturers of TPMs and all of them have different implementations. Some of them had been broken in the past, which is why it's important to make secrets PIN-dependent.
I seriously doubt the author found a way to bypass PIN protected setups in general. This should only be possible in combination with a vendor/model specific vulnerability. Maybe an fTPM?
As of this moment, I would rather look at it as a convenience feature. A high entropy password + a proper KDF (not possible on Windows) like scrypt or argon2 is the better choice. Encryption should be handled by SoC engines like on Macs, iPhones or some Android phones to mitigate other attacks and preserve performance anyway. Panther Lake CPUs with vPro support do on Windows.
Java really isn't fast unless you're basically writing C style Java. Abstracting is expensive in Java and if one can't abstract, what's the point of writing Java in 2026? After all these years value types aka Valhalla are still in a soon™ state. If it weren't for Project Loom, which is genuinely awesome, I wouldn’t see any justification for using Java in this day and age.
> Anyway, is mill worth switching away from Gradle?
Hard to say because I don't know how someone without Scala experience would fare with Mill. Then again, I think anything is better than Gradle. Really, anything. I even think I would do everything by hand rather than using Gradle. Also the creator of Mill is a great guy. Rest assured, if something's confusing or not working he's gonna help you out or fix it if necessary.
We have had lots of similar cases where people not only blindly followed new regulations (for example, regarding cash) but also encouraged them — and the justification was always the same: "Why do you use cash? Are you hiding something? Cash is for criminals!" Now that the government is about to monitor their chats, they suddenly complain. Why are you bothered by chat control? Are you hiding anything? Encryption is for criminals!