* ssh(1): Add a ssh_config(5) "Match" keyword that allows
conditional configuration to be applied by matching on hostname,
user and result of arbitrary commands.
* ssh(1): Add support for client-side hostname canonicalisation
using a set of DNS suffixes and rules in ssh_config(5). This
allows unqualified names to be canonicalised to fully-qualified
domain names to eliminate ambiguity when looking up keys in
known_hosts or checking host certificate names.
Both great things. I'm pretty excited about elliptic curve keys and the ability to have ProxyCommand-like ProxyUseFDPass return an fd instead of act as an long-lived intermediary, personally.
The Match keyword is great, but the syntax of "and continue reading until the end of the file" is a pain. They should add an EndMatch keyboard to close the block, or force indentation or something.
The Match keyword does allow you to configure based on your local address, so on first glance it would seem like it would allow you to do this, but for some reason ProxyCommand is not on the list of whitelisted keywords acceptable in a Match block. :/ That's really a shame.
I'm not saying DH/DLP is broken, but the NSA declines to include non-EC DH (or RSA, for that matter) in their Suite B of algorithms approved for internal applications. It's nice to have the option of ECDH for day to day use.
Shouldn't your laptop/disks be fully encrypted anyways? It's good to have a strong KDF, but the stolen laptop threat should be already covered, I'd hope.
True, but what if it's stolen while the laptop is turned on and the disk keys are in memory? I rarely shut my laptop off, and while I may be a little overly paranoid, it is certainly possible for a local attacker to gain memory bus access and read out disk encryption keys.
Or use monkeysphere and gpg keys that serve as ssh keys, which (gpg priv keys) is itself encrypted on encrypted disks with passphrase in an 10M rounds of AES25 encrypted password manager with a very long passphrase itself.
When you type in your password to decrypt your ssh private key on disk, it runs the string (and optionally also some salt, stored in the clear with the encrypted key to foil rainbowtable lookup attacks) through a key derivation function, or KDF. The output is used as the encryption key for the symmetric cipher that protects the key at rest.
One can use any cryptographically secure (output indistinguishable from random, infeasible to predict input given output, et c) hash as a KDF but the faster it is to run, the more per second an attacker can try when attempting to bruteforce your password/phrase after stealing your private key in its encrypted, on-disk format.
bcrypt is a function that is specifically designed to be somewhat time consuming to calculate (with a variable difficulty argument to the function itself), to reduce the bruteforce rate (in normal use, it's only run once or twice, once for each password input). Its cousin scrypt was specifically designed to also require a fair bit of memory to calculate, as well, reducing effective parallelism in fpga/asic implementations as the memory circuits must be included as well.
The difference between one <1ms hash and 100ms hash doesn't much matter to a user, but is the difference between a 10-char password being feasibly bruteforceable or not on dedicated hardware where you have to run 256^10 iterations. It adds up fast.
My ssh private key password is 8 chars that match [a-z0-9]. This matters a lot.
Ideally, a KDF should use as many resources as practical.
The NIST competition process of favoring performant algorithms is not always in the interests of users because it means it's cheaper to bruteforce/crack.
Key Derivation Function. It's a tool cryptographers use to derive cryptographic keys from different kinds of input material. Their most common use is to 'amplify' the entropy of a password or other low-entropy input and make it suitable for use as a key for a symmetric encryption scheme.
OpenSSH-HPN's patchset really needs to be merged into the mainline. There's no excuse for not at least incorporating dynamic window scaling into the core protocol since it's such a ridiculous omission at this point.
From a quick look I didn't see any license associated with these patches.
Searching around on the -misc archives, djm claims performance improvements similar to HPN and declares no interest in implementing the NONE cipher(no encryption after authentication).
Wonderful to see them using a modern, time-hard KDF finally.
One wonders where the kickstarter to get a proper time- and memory- hard KDF patched into GnuPG is? It's not even really that much of a compatibility issue, either (unless you are sharing private key files between many machines)...
You'd really think the tinfoil-hat paranoids that (until Snowden) comprise(d) the bulk of the pgp userbase would care about the keys used to keep their log-term keys on disk private. I was flabbergasted to see the (relatively) tiny number of iterations in use in the GnuPG kdf.
I forgot my PGP passphrase and can no longer sign Java packages in the Sonatype maven repository. This is not a big deal for me but I did try to recover my passphrase.
I got an extension to John the Ripper that supports Gnu PGP keys and built a dictionary of permutations of words that I think I could have used in the passphrase.
I got nowhere. In this case, a passphrase > 20 characters was unbreakable to someone with modest computing power and an appropriate dictionary.
Edit: I did not save a revoke certificate because the Sonatype instructions did not include this step.
How far you get as a private effort is not really characterizing the threat; the threat is a determined attacker with AMD GPUs by the dozen. And while it is easy to discount state-sized efforts as being uninterested in signing your Java packages, the real threat are the hobbyists and criminally minded pros who really do have rigs and really do brag about how they do go attack the long lists of hashed passwords that often turn up after website breaches.
Please use bcrypt on your new key, the one you will be writing down the password to ;)
More than a few people requested Github and Bitbucket to support more than RSA keys but they've both ignored the request for ECDSA for the last few years. The changes in 6.5 should inspire them to skip ECDSA and add Ed25519 as an option. Please Github and Bitbucket do everyone a favor and support modern keys. Next step is to save cpu cycles by using Curve25519 when available in the client. It's illogical not to.
"ChaCha" family of ciphers aim to increase the diffusion per round while achieving the same or slightly better performance.The Aumasson et al. paper also attacks ChaCha, achieving one round less: ChaCha6 with complexity 2^140 and ChaCha7 with complexity 2^231
