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

21–30 of 128 posts

Re: Psychic Signatures in Java

#21

Post by kasey_junk »

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.

This is true in principle but in practice most fuzz testing frameworks demand a fair bit of setup. It’s worth it!

But if you are in a time constrained environment where basic unit tests are skipped fuzz testing will be as well.

Re: Psychic Signatures in Java

#22

Post by tialaramex »

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.

[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 a unit test to check say, zero here. Can we also use fuzz testing? Sure, why not. But lines like this ought to scream out for a unit test.

Re: Psychic Signatures in Java

#23

Post by loup-vaillant »

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.

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 need two separate pieces of code to reject the =0 and >=n cases).

Another example is Poly1305. When you look at the test vectors from RFC 8439, you notice that some are specially crafted to trigger overflows that random tests wouldn't stumble upon.

Thus, I would argue that proper testing requires some domain knowledge. Naive fuzz testing is bloody effective but it's not enough.

Re: Psychic Signatures in Java

#24

Post by KronisLV »

yardstick wrote: post #17
KronisLV wrote: post #16

Earlier quoted context omitted.

> ...the Log4Shell vulnerability only applies to log4j 2.x (so if you stayed with log4j 1.x, and didn't explicitly configure it to use a vulnerable appender, you were safe) Seems like someone likes to live dangerously: using libraries that haven't been updated since 2012 is a pretty risky move, especially given that if an RCE is discovered now, you'll find yourself without too many options to address it, short of mig…

> using libraries that haven't been updated since 2012 is a pretty risky move I disagree. Some libraries are just rock solid, well tested and long life. In the case of log4j 1.x vs 2.x, has there been any real motivator to upgrade? There are 2 well known documented vulnerabilities in 1.x that only apply if you use extensions.

A sibling comment mentions the reload4j project, so clearly someone thought that 1.x wasn't adequate to a degree of creating a new project around maintaining a fork. Can't speak of the project itself, merely the fact that its existence supports the idea that EOL software is something that people would prefer to avoid, even if they decide to maintain a backwards compatible fork themselves, which is great to see.

Here's a bit more information about some of the vulnerabilities in 1.x, someone did a nice writeup about it: https://www.petefreitag.com/item/926.cfm

I've also dealt with 1.x having some issues with data loss, for example, https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4... which is unlikely to get fixed:

  DailyRollingFileAppender has been observed to exhibit synchronization issues and data loss.
(though at least in regards to that problem, there are alternatives; though for the most part EOL software implies that no further fixes will be available)

But at the end of the day none of it really matters: those who don't want to upgrade won't do so, potential issues down the road (or even current ones that they're not aware of) be damned. Similarly, others might have unpatched versions of 2.x running somewhere which somehow haven't been targeted by automated attacks (yet) and might continue to do so while there isn't proper motivation to upgrade, or won't do so until it will be too late.

Personally, i dislike the idea of using abandoned software for the most part, when i just want to get things done - i don't have the time to dance around old documentation, dead links, having to figure out workarounds for CVEs versus just using the latest (stable) versions and letting someone else worry about it all down the road. Why take on an additional liability, when most modern tooling and framework integrations (e.g. Spring Boot) will be built around the new stuff anyways? Though thankfully in regards to this particular case slf4j gives you more flexibility, but in general i'd prefer to use supported versions of software.

I say that as someone who actually migrated a bunch of old monolithic Spring (not Boot) apps to something more modern when the versions had been EOL for a few years and there were over a hundred CVEs as indicated by automated dependency/package scanning. It took months to do, because previously nobody actually cared to constantly follow the new releases and thus it was more akin to a rewrite rather than an update - absolute pain, especially that JDK 8 to 11 migration was also tacked on, as was containerizing the app due to environmental inconsistencies growing throughout the years to the point where the app would roll over and die and nobody had any idea why (ahh, the joys of working with monoliths, where even logs, JMX and heap dumps don't help you).

Of course, after untangling that mess, i'd like to suggest that you should not only constantly update packages (think every week, alongside releases; you should also release often) but also keep the surface area of any individual service small enough that they can be easily replaced/rewritten. Anyways, i'm going off on a tangent here about the greater implications of using EOL stuff long term, but those are my opinions and i simultaneously do admit that there are exceptions to that approach and circumstances vary, of course.

Re: Psychic Signatures in Java

#26

Post by LaputanMachine »

>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?

Re: Psychic Signatures in Java

#27

Post by lazide »

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?

Initial connection negotiation and key exchange does, anything after that no. It will use some kind of symmetric algo (generally AES).

It's a bad idea (and no one should be doing it) to continue using asymmetric crypto algorithms after that. If someone can get away with a pre-shared (symmetric) key, sometimes/usually even better, depending on the risk profiles.

Re: Psychic Signatures in Java

#28

Post by hsbauauvhabzb »

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 issue is the assumption juniors should be writing the unit tests, sounds like you might be part of the problem.

Re: Psychic Signatures in Java

#29

Post by smegsicle »

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?

if people were getting mad at him, he must have been pretty obnoxious about it because i don't think there's much controversy- Asymmetric encryption is pretty much just used for things like sharing the Symmetric key that will be used for the rest of the session

of course it would be more secure to have private physical key exchange, but that's not a practical option, so we rely on RSA or whatever

Post reply on HN