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

71–80 of 128 posts

Re: Psychic Signatures in Java

#71

Post by dilippkumar »

SAI_Peregrinus wrote: post #45
na85 wrote: post #38

Earlier quoted context omitted.

>infamous ECDSA nonce Why "infamous"?

It's more properly called 'k'. It's really a secret key, but it has to be unique per-signature. If an attacker can ever guess a single bit of the nonce with probability non-negligibly >50%, they can find the private key of whoever signed the message(s). It makes ECDSA very brittle, and quite prone to side-channel attacks (since those can get attackers exactly such information.

> If an attacker can ever guess a single bit of the nonce with probability non-negligibly >50%, they can find the private key of whoever signed the message(s).

This doesn’t seem right. Why wouldn’t someone guess a bit 0, see if the recovered message makes sense, and if it doesn’t, then try bit 1?

It would make the entire scheme useless no? Am I missing something?

Re: Psychic Signatures in Java

#72

Post by adgjlsfhk1 »

nicoburns wrote: post #41
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?

> Is there any truth to this? Yes, symmetric cryptography is a lot more straightforward and should be preferred where it is easy to use a shared secret. > Doesn't basically all Internet traffic rely on the security of (correctly implemented) asymmetric cryptography? It does. This would come under the "unless you absolutely need it" exception.

note that symmetric encryption is also really hard. it wasn't until 2010 or so that GCM mode came around and provided a system that is somewhat easy to implement without accidentally breaking everything.

Re: Psychic Signatures in Java

#73

Post by dwohnitmok »

loup-vaillant wrote: post #56
cliftonk wrote: post #31

Earlier quoted context omitted.

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.

Do you mean fuzz testing does not use even distributions? There’s a bias towards extrema, or at least some guarantee to test zero and MAX? I guess that would work. Also, would you consider the following to be fuzz testing? https://github.com/LoupVaillant/Monocypher/blob/master/tests...

No, most fuzz testing frameworks I know of these days do not use even distributions. Most use even more sophisticated techniques such as instrumenting the code to detect when state transitions are triggered to try to maximize hitting all code paths in a program instead of repeatedly fuzzing the same path.

Re: Psychic Signatures in Java

#74

Post by Thorrez »

dilippkumar wrote: post #71
SAI_Peregrinus wrote: post #45

Earlier quoted context omitted.

It's more properly called 'k'. It's really a secret key, but it has to be unique per-signature. If an attacker can ever guess a single bit of the nonce with probability non-negligibly >50%, they can find the private key of whoever signed the message(s). It makes ECDSA very brittle, and quite prone to side-channel attacks (since those can get attackers exactly such information.

> If an attacker can ever guess a single bit of the nonce with probability non-negligibly >50%, they can find the private key of whoever signed the message(s). This doesn’t seem right. Why wouldn’t someone guess a bit 0, see if the recovered message makes sense, and if it doesn’t, then try bit 1? It would make the entire scheme useless no? Am I missing something?

I think they have to get the bit repeatedly and then combine the biased signatures together mathematically to get the key.

Re: Psychic Signatures in Java

#75

Post by 0xdeadb00f »

adgjlsfhk1 wrote: post #72
nicoburns wrote: post #41

Earlier quoted context omitted.

> Is there any truth to this? Yes, symmetric cryptography is a lot more straightforward and should be preferred where it is easy to use a shared secret. > Doesn't basically all Internet traffic rely on the security of (correctly implemented) asymmetric cryptography? It does. This would come under the "unless you absolutely need it" exception.

note that symmetric encryption is also really hard. it wasn't until 2010 or so that GCM mode came around and provided a system that is somewhat easy to implement without accidentally breaking everything.

GCM is not without it's own pitfalls though, however.

Re: Psychic Signatures in Java

#76

Post by stolsvik »

needusername wrote: post #55
lobstey wrote: post #51

Not that a lot of companies are using the Java 15+. People generally stick to 8 or 11.

I believe Oracle 11 is affected.

I do not believe so. The "affected list" which includes 11 is for the complete set of the "CPU" - Critical Patch Update.

This specific one was introduced with the rewriting of these parts of the code from C++ to Java, and that happened with Java 15.

Re: Psychic Signatures in Java

#78

Post by hsbauauvhabzb »

tialaramex wrote: post #44
hsbauauvhabzb wrote: post #28

Earlier quoted context omitted.

The issue is the assumption juniors should be writing the unit tests, sounds like you might be part of the problem.

I think I probably technically count as a junior in my current role, which is very amusing and "I don't write enough unit tests" was one of the things I wrote in the self-assessed annual review. So, sure.

It’s more unit testing is everybodies job, especially complex cryptographic functions, which should really have at least two sets of eyes, or even two test case sets where each developer doesn’t see the other developers test cases to reduce the likelihood that positive bias may overlook missed tests.

But i say that as someone who regularly audits code with almost certainly no unit tests based on the quality of the applications, just one set would do me fine.

Post reply on HN