lambdafu's comments

I have the Widex SmartRIC 220, and would buy them again. They are comfortable, have musical audio quality (Widex works with musicians), very low latency (reducing comb filter effect), and in general look and feel very professional.

As for technology, they use bluetooth low energy to connect to the smart phone, which works really well, with the caveat that the range is quite low and if it is in the pocket and you are moving around, media sound will often disrupt or desync intermittently. On the plus side, they last well over a day even with media use (WIdex says they last 37 hours without bluetooth use and that checks out). The case provides charge for about a week, and has wireless and usb-c charging.

They are quite pricey, but there are several options (110, 220, 330, 440), and the 220 were more than enough for me. The app has several modes, including directional focus mode, and you can define your own. I sometimes use a different mode for listening to concert music, that disables most filters such as volume protection.

I am wearing them for 9 months now, and there was no situation (concerts, traveling, work, sports, etc) were they gave me any issues whatsoever.

Actually, with currently common key sizes, ECC up to 384 bits will fall to QC before RSA with 1024 bits, because fewer bits means fewer qubits needed.

The main disadvantage of RSA is the structure of finite fields, which allows specialized solutions to factoring (number field sieve). We do not know similar structures for elliptic curves, so for those we only have general attacks, thus allowing shorter key lengths.

For the attack all 60 signatures need a nonce that is special in this way. If for example only one out of the 60 is short, the attack fails in the lattice reduction step. The reason is that in the attack, all 60 short nonces "collude" to make up a very special short vector in the lattice, which is much shorter than usual because it is short in all 60 dimensions, not just one out of 500 dimensions. The approximate shortest vector is then obtainable in polynomial time, and this happens to contain the secret key by construction. As an analogy: Imagine you had a treasure map with 60 steps "go left, go right, go up, go down, go down again" etc. If only one out of 60 instructions where correct, you wouldn't know where the treasure is. All of the instructions need to be correct to get there.

Caution here. If your modulus is too close to the maximum truncated value, there can be a bias in the upper bits, too. For example, if you reduce a number between 0 and 15 by the modulus 13, the values 0, 1 and 2 will be twice as likely as the values 3-12. This means that the highest bit will be 0 in 11 out of 16 cases. Even such a small bias might be exploitable (for example, sub 1 bit bias up to 160-bit ECDSA here: Gao, Wang, Hu, He https://eprint.iacr.org/2024/296.pdf)

If the hosts are under your control, and never connect to untrusted hosts, then you are ok. The user authentication is encrypted, so the signatures are not visible to a man in the middle.

We found it by investigating the security of SSH as part of a larger research program focussing on SSH, which also resulted in our publication of the Terrapin vulnerability.

This particular bug basically fell into our hands while staring at the source code during our investigation of the security of SSH client signatures.

No, because there may be other messages that are ignored, i.e. don't trigger a response message. Any such message can be used for injection. The details are implementation specific, though. The new strict-kex disallows all unexpected messages during the initial handshake, which helps a lot. (Even better would be to authenticate the complete handshake transcript). Another mitigation is resetting the sequence number. Both together give some redundancy.

Depends a bit on the MAC. CTR-EtM is technically vulnerable (i.e. cryptographically broken), but due to key stream desynchronization the attack will quickly lead to application errors, defeating the attacker. See Sect. 4.3.3.

ChaPoly was added in 2013, but the weird KEX is even older, dating back all the way to 1998 in SSHv2. And surprisingly, the attack only works with the "better" symmetric ciphers that do INT-CTXT instead of INT-PTXT.

Thanks! <3 Also for the kind words.

It's prefix truncation, though.

NeoPG uses Botan, which is a crypto library written in C++. I recommend reading its source code and comparing it with, for example, libgcrypt.

Yes, I should document that. GPGME only exposes a high-level API, and application developers often want more control. For example, you can't inspect key material before importing it, but importing a key is not a reversible operation - so applications sometimes use a temporary HOMEDIR for GPGME/GnuPG to import the key there and inspect it with a keylisting. It can be very cumbersome.

Hi, I'm "this guy". Thanks for pointing out -fpermissive, which was needed during the conversion for the legacy code. Since then I fixed all the warnings, so I can remove the flag (https://github.com/das-labor/neopg/commit/5359aab7885628554c...).

I would love to do code review, but I need a second developer for that!

Thank you for your interest and taking the time to write down your criticism.