21–30 of 55 posts
What is the latest "most secure" crypto I should be using?
* ECDSA with secp-256 or ed25519 curves
* RSA >= 2048 bits. Performance takes a steep dive at 4096bits unfortunately
What people don't understand is that your implementation needs to be selected against your attack surface. If your attack surface includes hardening against side channels, your implementation selection needs to take that into account.
> the trustworthiness of NIST-produced curves being questioned after revelations that the NSA willingly inserts backdoors into software, hardware components and published standards were made; well-known cryptographers have expressed doubts about how the NIST curves were designed, and voluntary tainting has already been proved in the past. https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_...
'tptacek would write that no reputable cryptographer believes the NIST curves themselves are backdoored.
What is the latest "most secure" crypto I should be using?
https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
What is the latest "most secure" crypto I should be using?
For new designs: basically just use libsodium.
For SSH: Ed25519 or 2048 bit RSA.
We can get into the weeds about which specific cryptographic primitives are fine in isolation, but that misses the point — the ones that were fine 5-10 years ago are still more or less fine — the problems for developers and end-users generally stem from accidental misuse of cryptographic primitives in designing systems incorporating cryptographic primitives as a component. Sure, don't use DES, DSA, or MD5/SHA1; strong primitives are only necessary, not sufficient.
> the trustworthiness of NIST-produced curves being questioned after revelations that the NSA willingly inserts backdoors into software, hardware components and published standards were made; well-known cryptographers have expressed doubts about how the NIST curves were designed, and voluntary tainting has already been proved in the past. https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_...
There’s no reason I’m aware of to use ECDSA over other available crypto. Don’t use ECDSA.
1. They show libgcrypt managed to have the bug in EdDSA ( https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=c... ). 2. People need to use ECDSA for same reason they need to use RSA: compatibility. In particular, EdDSA webpki certificates will likely never happen ( https://cabforum.org/pipermail/servercert-wg/2019-June/00087... ).
Earlier quoted context omitted.
Can you say whether libgcrypt did something especially stupid? [1] I understand that most people just take the ref10 code from supercop, but if I were to try to implement ed25519 from the paper ( https://ed25519.cr.yp.to/papers.html ), what is the chance I would do something like what libgcrypt did, or equally bad? Basically, is ed25519 secure because everyone uses a known secure implementation or because it is engin…
If my two cents count, I would say that if you were to implement EdDSA from the paper, you would have a good chance of creating a secure implementation w.r.t. to this kind of leakage. However, if you were starting with some Short-Weierstrass EC code in your library, then you might be inclined to skip all the scalar multiplication specific stuff in the Ed25519 paper, just take some (incomplete) Edwards formulas, take…
Thank you for the explanation!
In https://minerva.crocs.fi.muni.cz/#details-reasons and in your comment you're describing two bad ways to do scalarmult, but you do not show side-by-side the correct way (e.g. what ref10 does). Can you describe it in a sentence or two?
Earlier quoted context omitted.
If my two cents count, I would say that if you were to implement EdDSA from the paper, you would have a good chance of creating a secure implementation w.r.t. to this kind of leakage. However, if you were starting with some Short-Weierstrass EC code in your library, then you might be inclined to skip all the scalar multiplication specific stuff in the Ed25519 paper, just take some (incomplete) Edwards formulas, take…
^ primary contact author of the paper in question Thank you for the explanation! In https://minerva.crocs.fi.muni.cz/#details-reasons and in your comment you're describing two bad ways to do scalarmult, but you do not show side-by-side the correct way (e.g. what ref10 does). Can you describe it in a sentence or two?
One of the main points in the root causes discussion is that without complete formulas you are almost always going to leak the bit-length, so the only way to not be vulnerable in that case is to fix the bit-length to a constant value. This cannot be done naively by simply setting the high bit, because this would introduce bias in the nonces which would be exploitable even without measuring the duration, a much worse attack! However it can be done via the method suggested by Brumley & Tuveri in https://eprint.iacr.org/2011/232 where you add a multiple of the curve order to the scalar to fix its bit-length. This means the distribution of the nonce modulo the order remains the same (uniform, no bias) yet the bit-length used in scalarmult as a loop bound is constant.
> the trustworthiness of NIST-produced curves being questioned after revelations that the NSA willingly inserts backdoors into software, hardware components and published standards were made; well-known cryptographers have expressed doubts about how the NIST curves were designed, and voluntary tainting has already been proved in the past. https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_...
'tptacek would write that no reputable cryptographer believes the NIST curves themselves are backdoored.
He's spent countless hours tirelessly denying the existence of programs that have subsequently been proven to exist. He clearly has a huge blindspot related to the potential for unlawful and unethical conduct by the US government.
What is clear enough about the NIST curves is that they used a high entropy process that would have easily allowed them to grind to select for undisclosed criteria, somewhat inexplicably. Maybe they used this fact to add security against currently non-public attacks? Maybe they used this fact to weaken them against an attack the public doesn't know about. Maybe, like tptacek, they were largely blind to the concern of government backdoors and just didn't care if the process looked somewhat janky. Regardless of the reason no clarification seems likely to every be made.
The more frustrating point is that the alternative of choice (curve25519/ed25519) is only available at the 252-bit security level, and current goverment guidance discourages ECC below 384 bits. Higher bit ed25519-alikes are no where near as mature or deployed. If your strategy is try to make choices where in the future you'll never have reason to feel stupid about the choices you made the options aren't really that great right now. You either use 384bit+ NIST and are exposed to the suspicious generation mechanism, use ed448 which is some weirdo cryptosystem few other things use, or use ed25519 and violate NSA's recommendation to use >=384 bits. With each of those options if it later turns out to be a bad choice you'll have plenty of reason to feel stupid.