Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Psychic Signatures in Java

neilmadden.blog

Post reply on HN
Print view View original

31–40 of 128 posts

Re: Psychic Signatures in Java

#31

Post by cliftonk »

loup-vaillant wrote: post #23
tptacek wrote: post #13

Earlier quoted context omitted.

The point of fuzz testing is not having to think of test cases in the first place.

You still need your tests to cover all possible errors (or at least all plausible errors). If you try random numbers and your prime happens to be close to a power of two, evenly distributed random numbers won't end up outside the [0,n-1] range you are supposed to validate. Even if your prime is far enough from a power of two, you still won't hit zero by chance (and you need to test zero, because you almost certainly…

That’s all true, but fuzz testing is very effective at checking boundary conditions (near 0, near max/mins) and would have caught this particular problem easily.

Re: Psychic Signatures in Java

#32

Post by tptacek »

tialaramex wrote: post #22
tptacek wrote: post #13

Earlier quoted context omitted.

The point of fuzz testing is not having to think of test cases in the first place.

[Somebody had down-voted you when I saw this, but it wasn't me] These aren't alternatives, they're complementary. I appreciate that fuzz testing makes sense over writing unit tests for weird edge cases, but "these parameters can't be zero" isn't an edge case, it's part of the basic design. Here's an example of what X9.62 says: > If r’ is not an integer in the interval [1, n-1], then reject the signature. Let's write…

Right, I'm just saying: there's a logic that says fuzz tests are easier than specific test-cases: the people that run the fuzz tests barely need to understand the code at all, just the basic interface for verifying a signature.

Re: Psychic Signatures in Java

#33

Post by brazzy »

ragnese wrote: post #14
cesarb wrote: post #11

And once again, you'd be saved if you stayed on an older release. This is the third time this has happened recently in the Java world: the Spring4Shell vulnerability only applies to Java 9 and later (that vulnerability depends on the existence of a method introduced by Java 9, since all older methods were properly blacklisted by Spring), and the Log4Shell vulnerability only applies to log4j 2.x (so if you stayed with…

Was Spring4Shell Java's fault, or Spring's fault? Log4Shell was obviously (mostly) log4j's fault. This one, I gather, is actually Java's fault. It sounds like three unrelated security bugs from totally different teams of developers.

I think they other two are considered "Javas's fault" because the frameworks they occurred in are so pervasive in the Java ecosystem that you might as well consider them part of the standard library.

Re: Psychic Signatures in Java

#34

Post by anfilt »

tptacek wrote: post #13
tialaramex wrote: post #8

This is the sort of dumb mistake that ought to get caught by unit testing. A junior, assigned the task of testing this feature, ought to see that in the cryptographic signature design these values are checked as not zero, try setting them to zero, and... watch it burn to the ground. Except that, of course, people don't actually do unit testing, they're too busy. Somebody is probably going to mention fuzz testing. But…

The point of fuzz testing is not having to think of test cases in the first place.

While fuzz testing is good and all, when it comes to cryptography, the input spaces is so large that chances of finding something are even worse than finding a needle in a hay stack.

For instance here the keys are going to be around 256 bits in a size, so if your fuzzer is just picking keys at random, your basically never likely to pick zero at random.

With cryptographic primitives you really should be testing all known invalid input parameters for the particular algorithm. A a random fuzzer is not going to know that. Additionally, you should be testing inputs that can cause overflows and are handled correctly ect...

Re: Psychic Signatures in Java

#36

Post by fabian2k »

LaputanMachine wrote: post #26

>Just a basic cryptographic risk management principle that cryptography people get mad at me for saying (because it’s true) is: don’t use asymmetric cryptography unless you absolutely need it. Is there any truth to this? Doesn't basically all Internet traffic rely on the security of (correctly implemented) asymmetric cryptography?

I've seen this argument often on the topic of JWTs, which are also mentioned in the tweets here. In many situations there are simpler methods than JWTs that don't require any cryptography, e.g. simply storing session ids server-side. With these simple methods there isn't anything cryptographic that could break or be misused.

The TLS encryption is of course assumed here, but that is nothing most developers ever really touch in a way that could break it. And arguably this part falls under the "you absolutely need it" exception.

Re: Psychic Signatures in Java

#37

Post by jaywalk »

fabian2k wrote: post #36
LaputanMachine wrote: post #26

>Just a basic cryptographic risk management principle that cryptography people get mad at me for saying (because it’s true) is: don’t use asymmetric cryptography unless you absolutely need it. Is there any truth to this? Doesn't basically all Internet traffic rely on the security of (correctly implemented) asymmetric cryptography?

I've seen this argument often on the topic of JWTs, which are also mentioned in the tweets here. In many situations there are simpler methods than JWTs that don't require any cryptography, e.g. simply storing session ids server-side. With these simple methods there isn't anything cryptographic that could break or be misused. The TLS encryption is of course assumed here, but that is nothing most developers ever really…

Server-side session storage isn't necessarily a replacement for JWTs. It can be in many cases, but it's not one to one. JWTs do have advantages.

Re: Psychic Signatures in Java

#38

Post by na85 »

tptacek wrote: post #2

This is probably the cryptography bug of the year. It's easy to exploit and bypasses signature verification on anything using ECDSA in Java, including SAML and JWT (if you're using ECDSA in either). The bug is simple: like a lot of number-theoretic asymmetric cryptography, the core of ECDSA is algebra on large numbers modulo some prime. Algebra in this setting works for the most part like the algebra you learned in 9…

>infamous ECDSA nonce

Why "infamous"?

Re: Psychic Signatures in Java

#39

Post by fabian2k »

jaywalk wrote: post #37
fabian2k wrote: post #36

Earlier quoted context omitted.

I've seen this argument often on the topic of JWTs, which are also mentioned in the tweets here. In many situations there are simpler methods than JWTs that don't require any cryptography, e.g. simply storing session ids server-side. With these simple methods there isn't anything cryptographic that could break or be misused. The TLS encryption is of course assumed here, but that is nothing most developers ever really…

Server-side session storage isn't necessarily a replacement for JWTs. It can be in many cases, but it's not one to one. JWTs do have advantages.

That's why I wrote "in many cases". The problem is more that for a while at least JWT were pretty much sold as the new and shiny replacement for classic sessions, which they're not. They absolutely have their uses, but they also have additional attack surface.

Re: Psychic Signatures in Java

#40

Post by slaymaker1907 »

fabian2k wrote: post #36
LaputanMachine wrote: post #26

>Just a basic cryptographic risk management principle that cryptography people get mad at me for saying (because it’s true) is: don’t use asymmetric cryptography unless you absolutely need it. Is there any truth to this? Doesn't basically all Internet traffic rely on the security of (correctly implemented) asymmetric cryptography?

I've seen this argument often on the topic of JWTs, which are also mentioned in the tweets here. In many situations there are simpler methods than JWTs that don't require any cryptography, e.g. simply storing session ids server-side. With these simple methods there isn't anything cryptographic that could break or be misused. The TLS encryption is of course assumed here, but that is nothing most developers ever really…

You can still use encryption with JWTs if you use a symmetric key. I believe HS256 just uses a symmetric key HMAC with SHA256. If you go beyond JWT, Kerberos only uses symmetric cryptography while not being as centralized as other solutions. Obviously, the domain controller is centralized, but it allows for various services to use common authentication without compromising the whole domain if any one service is compromised (assuming correct configuration which is admittedly difficult with Kerberos).
Post reply on HN