Not that a lot of companies are using the Java 15+. People generally stick to 8 or 11.
Psychic Signatures in Java
51–60 of 128 posts
Re: Psychic Signatures in Java
#52Earlier 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.
That makes no sense, how can you get the private key from knowing 1 bit of the nonce?
Re: Psychic Signatures in Java
#53Q: Which type of cryptography is implied to be unsafe in the following sentence?: "Immediately ditch RSA in favor of EC, for it is too hard to implement safely!"
What's java's RSA history look like?
Re: Psychic Signatures in Java
#54>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…
The biggest problem with JWTs is not what cryptography you use (though there was a long standing issue where "none" was something that clients could enter as a client side attack...) but rather revocation.
x509 certificates have several revocation mechanisms since having something being marked as "do not use" before the end of its lifetime is well understood. JWTs are not quite there.
Re: Psychic Signatures in Java
#55Not that a lot of companies are using the Java 15+. People generally stick to 8 or 11.
I believe Oracle 11 is affected.
Re: Psychic Signatures in Java
#56Earlier quoted context omitted.
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.
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...
Re: Psychic Signatures in Java
#57Earlier 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…
The biggest problem with JWTs is not what cryptography you use (though there was a long standing issue where "none" was something that clients could enter as a client side attack...) but rather revocation. x509 certificates have several revocation mechanisms since having something being marked as "do not use" before the end of its lifetime is well understood. JWTs are not quite there.
JWT is just a container for authenticated data. it's comparable to the ASN.1 encoding of an x509 certificate, not to the entire x509 public key infrastructure.
You could compare x509 with revocation to something like oauth with JWT access tokens, though.
In that case, x509 certificates are typically expensive to renew and have lifetimes measured in years. Revocation involves clients checking a revocation service. JWT access tokens are cheap to renew and have lifetimes measured in minutes. Revocation involves denying a refresh token when the access token needs renewing. Clients can also choose to renew access tokens much more frequently if a 'revocation server' experience is desirable.
Given the spotty history of CRLDP reliability, I think oauth+JWT are doing very well in comparison. I'm pretty damn confident that when I revoke an application in Google or similar it will lose access very quickly.
Re: Psychic Signatures in Java
#58Earlier 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.
That makes no sense, how can you get the private key from knowing 1 bit of the nonce?
See, cryptography engineering is sinking in!
Here you go:
https://toadstyle.org/cryptopals/62.txt
What's especially great about this is that it's very easy to accidentally have a biased nonce; in most other areas of cryptography, all you care about when generating random parameters is that they be sufficiently (ie, "128 bit security worth") random. But with ECDSA, you need the entire domain of the k value to be random.
Re: Psychic Signatures in Java
#59Earlier 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.
That makes no sense, how can you get the private key from knowing 1 bit of the nonce?
I guess like so:
https://cryptopals.com/sets/8/challenges/62.txt
E: Thomas beat me to it
Re: Psychic Signatures in Java
#60Earlier 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.
There's an easy fix for that though -- generate k deterministically using the procedure in RFC6979 [1].
[1] https://datatracker.ietf.org/doc/html/rfc6979#section-3.2