An error as small as a single flipped memory bit is all it takes to expose a private key. //

Martin Blank Ars Tribunus Militum

gromett said:
I have read it twice and am still not entirely clear.
Does this affect OpenSSH? As I read it the answer is no?

As happens often in cryptographic attacks that at least start out as implementation-specific, the likely answer is "it is not currently known to affect other implementations." Cryptographic techniques always get cheaper, never more expensive, and it is difficult to guarantee that other implementations are not vulnerable through variations of this attack. //

bobo bobo said:
A link in this article, to a Wikipedia page on Man In the Middle attacks, is labeled as a "malory in the middle" attack. But, um, the Wikipedia page does not use the term "malory". I am confused by use of the word "malory".

Typo? Or am I missing something?
It's a less common use, but it's part of the movement in the IT industry to move away from sensitive terms (e.g., master/slave becoming primary/secondary or similar). I've also heard monster-in-the-middle and monkey-in-the-middle, but really, there are no suggested terms that roll off the tongue the way man-in-the-middle does while keeping the MitM shorthand. //

FabiusCunctator Ars Scholae Palatinae

The vulnerability occurs when there are errors during the signature generation that takes place when a client and server are establishing a connection. It affects only keys using the RSA cryptographic algorithm, which the researchers found in roughly a third of the SSH signatures they examined.

A good reason to not use RSA keys if possible. I configure all of my ssh setups to use ED25519 keys by default, with a fallback to RSA if ED25519 support is not available.

You can generate an ED25519 key using the standard OpenSSH package by doing:

 ssh-keygen -t ed25519

That will generate two files in your ssh key directory ('~/.ssh/' by default): 'id_ed25519' and 'id_ed25519.pub'. The first is your private key (keep it close!), while the second is your public key. Add that to the public key file you deploy to remote servers, and (where supported *) your logins will then use the new ED25519 keypair in preference to RSA ones.

• The 'where supported' caveats are important. While many if not most ssh implementations today (including OpenSSH) support ED25519 keys, there are still a few around that don't. Hence, it's a good idea to maintain both ED25519 and RSA keys and include both in your public key lists. If an implementation does not support ED25519, it will just ignore those keys and use RSA. //