Files for ssh, version 1.8.0; Filename, size File type Python version Upload date Hashes; Filename, size ssh-1.8.0.tar.gz (795.8 kB) File type Source Python version None Upload date Oct 29, 2012 Hashes View. HFT410-1SBVY-8 HELIAX® FiberFeed® Hybrid Cable Assembly, BiDi, 6-OVP box to RRU, UL Type TC-ER, 4 power conductors 10 AWG at OVP, 2 power cords 8 AWG at RRU, 1 Simplex fiber connectors, PVC jacket, aluminum armor, grommet FA-6627-3315-GKHP is required for power cord se.

The OpenSSH 8.3 release is out. This primarily a bug-fix release with ahandful of minor new features. It does, however, carry a prominent noticethat ssh-rsa signature algorithm will be disabled in 'a near-futurerelease'. The announcement includes information on how to determinewhether hosts you care about are affected.

From:	Damien Miller <djm-AT-openbsd.org>
To:	oss-security-AT-lists.openwall.com
Subject:	[oss-security] Announce: OpenSSH 8.3 released
Date:	Wed, 27 May 2020 00:12:59 -0600 (MDT)
Message-ID:	<9739d4a6516e888a@openbsd.org>
Archive-link:	Article

(Log in to post comments)

Serious questions: how worried should I be?

Posted May 27, 2020 17:11 UTC (Wed) by floppus (subscriber, #137245) [Link]

What algorithms do other SSH implementations support? (Has anybody here tried turning off ssh-rsa and have you gotten any complaints from users?)

I've been very leery of using ECDSA, since as I understand it, a less-than-perfect random number generator allows an attacker to determine your secret key. For SSH host/client public keys this seems especially dangerous, since there's effectively no key rotation. Am I being overly paranoid about this?

What specifically is the danger of chosen-prefix attacks on SHA-1 - how would those be used to attack SSH host or client authentication?

Serious questions: how worried should I be?

Posted May 27, 2020 17:39 UTC (Wed) by josh (subscriber, #17465) [Link]

On a server, disabling ssh-rsa seems quite safe; users can easily generate a new key. It generates some minor grumbling, but with a well-communicated rationale, users can handle it.

On the flip side, though: I regularly run into servers that only support ssh-rsa keys, such as git repository hosting sites that have web interfaces to provide public keys. Many of those sites aren't using OpenSSH's sshd, they're using library implementations of ssh and not supporting full shells. Perhaps this deprecation will help motivate such servers to move forward.

Personally, I think ssh-ed25519 seems like a reasonable path forward.

Serious questions: how worried should I be?

Posted May 27, 2020 17:57 UTC (Wed) by smcv (subscriber, #53363) [Link]

Note that even if both client and service have RSA keys whose *public key format* starts with 'ssh-rsa ' (in ~/.ssh/id_rsa.pub and /etc/ssh/ssh_host_rsa_key.pub respectively), they are not necessarily using the ssh-rsa *host key algorithm*.

Assuming both the client and the server are a vaguely recent version of OpenSSH, or something else that implements newer algorithms, the same public keys can be used with the rsa-sha2-512 and rsa-sha2-256 host key algorithms, which are believed to be OK. The announcement does say this ('These algorithms have the advantage of using the same key type as 'ssh-rsa'), but perhaps that isn't making it clear enough.

For example:

$ ssh -vvv -oHostKeyAlgorithms=rsa-sha2-512,rsa-sha2-256 people.debian.org
...
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256
...
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
...
debug1: Server host key: ssh-rsa SHA256:[redacted1]
...
debug1: Host 'people.debian.org' is known and matches the RSA host key.
...
debug1: Will attempt key: /home/[redacted].pub RSA SHA256:[redacted2] explicit agent
...
debug3: sign_and_send_pubkey: RSA SHA256:[redacted2]
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:[redacted2]

(My only public key that people.debian.org is configured to accept is RSA, and for this example I told my ssh client not to try validating people.debian.org's non-RSA host keys.)

I think the biggest problem here is going to be with non-OpenSSH client and server implementations, which might only implement the mandatory-to-implement ssh-rsa algorithm if they are a minimum-viable-product sort of implementation.

Serious questions: how worried should I be?

Posted May 31, 2020 1:05 UTC (Sun) by dtucker (subscriber, #6575) [Link]

> I think the biggest problem here is going to be with non-OpenSSH client and server implementations,

You'll be able to re-enable it in the config for those cases.

> which might only implement the mandatory-to-implement ssh-rsa algorithm

ssh-rsa is RECOMMENDED not mandatory. The only REQUIRED public key algorithm in RFC4253 is ssh-dss (aka DSA, which you can still re-enable in the config if you need).

Serious questions: how worried should I be?

Posted May 29, 2020 11:32 UTC (Fri) by cjwatson (subscriber, #7322) [Link]

One such library is Python's Twisted package, which at least supports ECDSA, though many people don't like that for various reasons. I recently landed support for Ed25519 there, in large part because I wanted to be able to support it for keys used on git.launchpad.net; though it hasn't made it into a released version yet, and at the moment it only works with a fairly recent version of OpenSSL at the server end.

As for the ssh-rsa public key signature algorithm, I'd just like to note that we had a very similar conversation in the LWN comment thread following the OpenSSH 8.2 release announcement. (OpenSSH often repeats substantially the same deprecation notices across multiple release announcements. In this case, the only difference is the addition of this sentence near the end: 'Vendors of devices that implement the SSH protocol should ensure that they support the new signature algorithms for RSA keys.')

Serious questions: how worried should I be?

Posted May 27, 2020 17:53 UTC (Wed) by patrakov (subscriber, #97174) [Link]

Serious questions: how worried should I be?

Posted May 27, 2020 18:11 UTC (Wed) by smcv (subscriber, #53363) [Link]

Serious questions: how worried should I be?

Posted May 27, 2020 19:55 UTC (Wed) by hmh (subscriber, #3838) [Link]

Serious questions: how worried should I be?

Posted May 27, 2020 18:55 UTC (Wed) by brunowolff (guest, #71160) [Link]

Serious questions: how worried should I be?

Posted May 27, 2020 19:15 UTC (Wed) by jonesmz (subscriber, #130234) [Link]

Serious questions: how worried should I be?

Posted May 27, 2020 23:54 UTC (Wed) by wahern (subscriber, #37304) [Link]

OpenSSL 1.1 mitigates this problem by hashing the private key and the message along with any randomness to generate the signing nonce. The nonce will always be at least as unpredictable as your private key, so long as SHA-512 is secure.

See https://github.com/openssl/openssl/commit/8a99cb29d1f0013... (original patch adding the mitigation as an option) and https://github.com/openssl/openssl/commit/190c615d4398cc6... (making the mitigation the default and, AFAICT, only method). See BN_generate_dsa_nonce for the implementation.

I only use hardware tokens for SSH, few of which support EdDSA. I wonder how common this mitigation is in other implementations.

Serious questions: how worried should I be?

Posted May 28, 2020 12:21 UTC (Thu) by judas_iscariote (subscriber, #47386) [Link]

> since as I understand it, a less-than-perfect random number generator allows an attacker to determine your secret key

OpenSSL uses rfc 6979-style k generation by default. just use openssl 1.1 and you will be fine.

Serious questions: how worried should I be?

Posted Jun 3, 2020 14:33 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

Others have explained that using RSA keys remains fine so long as both clients and servers know a better hash for them than SHA-1. The public RSA keys you know (in your authorized_keys file and in known-hosts) work fine with any of the newer hashes defined in more recent RFCs for SSH.

Ssh 80 Port

There is no specific direct danger from chosen prefix attacks on SHA-1 when it comes to SSH authentication. But SHA-1 is defined as a cryptographic hash, a chosen prefix attack ought to be effectively impossible, not merely 'quite difficult' or 'somewhat expensive'. So clearly SHA-1 is not fulfilling its stated purpose.

So you should stop using SHA-1, the same way you'd stop using a microwave oven that has begun to spark and smoke. In principle sparks and smoke could just be contained and you can still use the oven, the magnetron doesn't mind a few wisps of smoke. But the oven isn't supposed to do this, maybe it will just keep emitting smoke but never actually catch fire. Best not to find out.

ssh-rsa deprecation

Posted May 27, 2020 22:33 UTC (Wed) by geuder (subscriber, #62854) [Link]

Does this affect host keys and user keys alike? The test given there seems to cover only host keys.

In some internal company servers I have installed nothing but ed25519 host keys for quite a while. No problems have been observed.

For user keys we use gpg authentication subkeys. (The reasoning was that we use GPG already elsewhere in our processes and by using subkeys it's easier to track whom a public key belongs to because we all have them on our GPG public keyrings already.)

When the policy was written there were still gpg versions in use that did not allow to export ed25519 keys in ssh format. It was also said that HW dongles could not necessarily handle ed25519. So rsa was originally mandated and is still allowed today.

As a result older users have rsa authentication subkeys, newer ones mostly use ed25519. Do we need to phase out the rsa authentication subkeys?

ssh-rsa deprecation

Posted May 28, 2020 8:15 UTC (Thu) by smcv (subscriber, #53363) [Link]

ssh-rsa deprecation

Posted May 29, 2020 4:23 UTC (Fri) by geuder (subscriber, #62854) [Link]

Thanks for your reply. I had read your previous comment, but my understanding of cryptography was not sufficient to apply it to my question :(

So the algorithm question is called ssh-rsa, but the most vulnerable part is not rsa, it's SHA-1. SHA-1 is used for fingerprinting in ssh-rsa, despite not appearing in the name.

In known_hosts we have fingerprints I guess, so that needs updating (accepting a new one after an affected server has been upgraded). In authorized_keys we don't have fingerprints so that remains unaffected?

Did I guess all this correctly now? I don't dare to use the word understand here...

ssh-rsa deprecation

Posted May 29, 2020 6:08 UTC (Fri) by pabs (subscriber, #43278) [Link]

ssh-rsa deprecation

Posted May 29, 2020 20:26 UTC (Fri) by geuder (subscriber, #62854) [Link]

Of course, one should not post comments at half past seven in the morning from the phone without running a trivial cat command before...

I had the clear picture in my mind that all my entries in known_hosts are pretty short (unlike rsa_keys). So I guessed they must be fingerprints. And of course we are prompted to access the fingerprint. But encrypting a secret using a fingerprint would not be possible, so this was a stupid idea. The reason for the shortness I did correctly remember is that I mostly have ssh-ed25519 entries with a couple of ecdsa-sha2-nistp256 exceptions.

It has always been against my intuition of information theory that the short ed25519 keys are said to be more secure than the much longer rsa keys. Just unscientifically looking at the public keys I paste into authorized_keys files. But a brute force attack against a 'short' ed25119 key seems already quite infeasible, so maybe I should stop wondering and hope the cryptographers are right :)

ssh-rsa deprecation

Posted May 30, 2020 6:53 UTC (Sat) by geuder (subscriber, #62854) [Link]

> It has always been against my intuition of information theory that the short ed25519 keys are said to be more secure than the much longer rsa keys

Let me try to answer myself: Could this be caused by the prime number theorem? https://en.m.wikipedia.org/wiki/Prime_number_theorem The bigger numbers get the rarer the prime numbers are. RSA keys contain big primes. Coding big primes in binary is awfully wasteful, because you know that all non-primes are not valid code points, they are wasted. Using the prime-counting function would optimize for space, but the time penalty would be prohibitive. If counting primes were fast brute forcing RSA would be fast, too.

(Disclaimer: Based on decades old high school math. Don't run your own cryptography, it will be awfully wrong.)

ssh-rsa deprecation

Posted May 30, 2020 12:41 UTC (Sat) by Wol (subscriber, #4433) [Link]

> The bigger numbers get the rarer the prime numbers are

I think that's wrong ... the average gap between two large primes isn't THAT much bigger than between two small primes. That's one of the reasons cracking RSA is hard - there are so many primes that even when you've found one, the chances of it being the right one are still a 'needle in a haystack' problem ...

Cheers,
Wol

ssh-rsa deprecation

Posted Jun 2, 2020 10:33 UTC (Tue) by DigitalBrains (subscriber, #60188) [Link]

No, it's correct, the larger the prime, the larger the gap. From the linked Wikipedia page:
> This means that for large enough N, the probability that a random integer not greater than N is prime is very close to 1 / log(N).

And the two primes in a 2048-bit key are 1024-bit numbers, so they lie between 2**1023 and 2**1024-1. You don't even get all the primes less than 2**1023 thrown in the bag.

Conversely, every integer in the range 0 to 2**256-1 is a candidate for an ed25519 secret key, a much more densely populated keyspace.

Still, the number of 1024-bit primes is a massive search space. Just not quite as mind-bogglingly massive as 2**1024 candidates.

ssh-rsa deprecation

Posted Jun 3, 2020 13:37 UTC (Wed) by jwilk (subscriber, #63328) [Link]

Per the prime number theorem, the number of 1024-bit primes is ~2¹⁰¹⁴. That 10-bit gap is negligible, because we have much better factorization algorithms than brute force: NIST estimates that 2048-bit RSA provides only ~112 bits of security.

ssh-rsa deprecation

Posted Jun 7, 2020 14:16 UTC (Sun) by DigitalBrains (subscriber, #60188) [Link]

Right, I should just have done the math or at least realised how small the log(N) term really was. 2¹⁰¹⁴ is just as mind-bogglingly massive as 2¹⁰²⁴! Thanks for pointing it out.

The size of the key space is usually not what determines the security of the algorithm: elliptic curve crypto isn't as profitable as that either. Any concrete numbers actually reflect the current state of the art, not some intrinsic property of the algorithm. So if we say something has 112 bits of security, we mean with the currently known attacks. In five years, it might be down to a meager 50 bits if we discover a devastating attack. And someone might have discovered this attack already.

So if you believe NIST in 2016, they said (table 2) that a 2048-bit RSA key gives you about 112 bits, 3072 for 128 bits, 7680 for 192 bits, 15360 for 256 bits. That scales really poorly, immense diminishing returns. And just working with these RSA keys also has rather high computational complexity, so it takes much more processing power to work with a 7680 bits key than the smaller ones.

From that same table, we see elliptic curve cryto scaling more favourably: a 224-bit secret key gives you 112 bits, 256 gives you 128 bits, 384 gives you 192 bits and 512 gives you 256 bits (it's just linear so far). And the processing power to work with these keys is an awful lot less than for RSA. However, hardware acceleration is more widely available for RSA.

TL;DR: don't directly compare key sizes between different families of algorithms. That's really the point I wanted to make here.

ssh-rsa deprecation

Posted May 30, 2020 12:56 UTC (Sat) by Sesse (subscriber, #53779) [Link]

It's unintuitive because you are asking the wrong question. The question isn't really “how many possible keys are there”, it's “how many operations do I need to figure out the private key”.

For symmetric cryptography, your intuition generally makes sense; for any competently-designed cipher, there really is no substantially better way than just trying all keys on the material you're trying to decrypt and seeing which one decrypts into something that looks like plaintext. There might be attacks that move this from, say, 2^128 to 2^120, but you still have huge amounts of practical margins.

However, for public-key cryptography, you have the public key! So the question is whether you can easily reverse the private-to-public key transformation or not. (It's generally very easy to go from private key to public key, although the details vary between cryptosystems.) For traditional RSA and DSA, we know of very efficient algorithms for doing this. Say that you have a 256-bit RSA key; the modulus N (part of the public key) would consist of two primes on the order of 2^128 each, multiplied together. If all we had was brute force, there would be approximately 2^121 primes to try, give or take a few. But with algorithms such as the number field sieve (NFS, not related to the network protocol), we can factor such numbers in seconds or even milliseconds on modern hardware. The only recourse we have is to make the keys huge, since no known polynomial-time factoring algorithm exists on classical hardware. (Quantum computers, if they practically realizable, would do much better.) The general advice today is 4096-bit RSA, which seems to have a sescurity level somewhat better than 2^128; ie., factoring a 3072-bit RSA key with modern algorithms is supposed to take about as much work as bruteforcing a 128-bit secret key.

Elliptical-curve algorithms, such as ECDSA and Ed25519, generally work similarly to DSA (which, for deep math-y reasons, is very similar to RSA, even though it looks superficially different), but they don't use the regular integers as the basic building blocks. Instead, they use points on some special curves, which for more deep math-y reasons seem to lack some of the structure needed by algorithms such as NFS. So for e.g. Ed25519, it seems that a 256-bit key really has a security level of 2^256. In other words, since we know of no clever algorithms to go from private to public key (we could probably do Pollard's rho, but I don't think it helps much), we are back to just trying every single possible private key, converting it to a public key and see if it matches.

So there your intuition is back again; for Ed25519, the question is how many possible keys there are. But for RSA, it's not. And that's why the RSA keys are so much longer, for a security level that's actually a bit worse. Unless there's some wild breakthrough in elliptical-curve mathematics, of course.

ssh-rsa deprecation

Posted May 30, 2020 21:53 UTC (Sat) by Wol (subscriber, #4433) [Link]

Except, with elliptical curve cryptography, you need to pick your numbers carefully. There was some hardware out there where the figures were chosen badly (on purpose?) with the result that the key space was much smaller than it appeared to be. I think certain elliptical curves are known not to be good, or something like that.

With RSA, provided you really do have two primes (yes you can get it wrong), there really is no easy way to break it.

Cheers,
Wol

ssh-rsa deprecation

Posted May 30, 2020 22:06 UTC (Sat) by Sesse (subscriber, #53779) [Link]

With Ed25519, you don't need to be careful as long as your random generator is good. Pick 32 random bytes, then do

mysecret[0] &= 248;
mysecret[31] &= 127;
mysecret[31] |= 64;

and that's your secret key. Zero care needed. If your random generator is bad, your key will be easier to brute-force, but there isn't disastrous breakdown (i.e., one bad bit leads to one bit less to brute-force, but the scheme doesn't collapse).

ssh-rsa deprecation

Posted May 31, 2020 14:46 UTC (Sun) by farnz (subscriber, #17727) [Link]

The problem is not in the numbers you choose for your keys, in either cryptosystem. It's in the parameters used to define the finite field (a.k.a Galois field) you're working in.

For RSA, you're always working with a finite field in the real numbers, defined by n (the modulus) and e (the exponent), which form the public key. Assuming prime factoring remains hard, determining d (the private key) is hard.

With elliptic curves, you're working in a finite field defined by the curve parameters; for Ed25519, the field comes from the prime 2^255 - 19, generating values on the elliptic curve y^2 = x^3 + 486662 * x^2 + x. There's an infinite number of primes and of curves that can be used; however, the security in elliptic curves comes from the assumption that the constants in the curve have been correctly chosen to make the discrete logarithm problem on that curve hard.

Now, I have no reason to distrust DJB's reasoning for choosing a curve of the form y^2 = x^3 + A * x^2 + x, nor do I have cause to distrust his choice of A = 486662. However, if he was evilly inclined, it is possible to construct a curve where the result is secure against everyone who does not know how the curve was constructed, but enables the curve constructor to solve the discrete logarithm problem on that curve in reasonable time.

That last is what the NSA is suspected of doing; we know that for Dual_EC_DRBG, they selected two apparently unique curves P and Q, but knew that they were in fact related where dP = Q, and the NSA knew d. Because of this knowledge, they could identify the state of the DRBG from its output, but they needed to know d to do that - no-one else could do the same without first solving dP = Q for d, which is also a hard problem.

However, we suspect as a result of this that for P-256 and other NIST curves the NSA had an involvement in, they chose the constants (e.g. A above) such that they know how to solve the discrete logarithm problem on that curve, but nobody else does (because it depends on knowing two curves that combine to form the attacked curve).

ssh-rsa deprecation

Posted May 31, 2020 15:09 UTC (Sun) by Sesse (subscriber, #53779) [Link]

Both 2^255 - 19 and 486662 are “nothing up my sleeve” numbers, explained in the Curve25519 paper. 2^255 - 19 is the closest prime to a power of two below 256 bits, and 486662 is the smallest number that correspond to a set of (fairly reasonable) criteria. So they're not arbitrarily chosen; of course, it is entirely possible to fudge said criteria, and it's possible that djb knows some sort of elliptical-curve attack on the y^2 = x^3 + A * x^2 + x curves that nobody else does, but it's not like Dual_EC_DRBG where suddenly a set of constants are presented out of thin air with no justification.

The NIST curves (P-256 etc.) are also somewhat different; the coefficients come out of SHA-1 of a seed, which means at least NIST cannot have completely freely chosen parameters. (The worst thing they could do is probably to try a bunch of seeds and generate parameters with weaknesses only they knew about, which sounds a bit far-fetchde.) Their main problem is that they're easy to mess up when implementing, and are rather slow.

ssh-rsa deprecation

Posted May 31, 2020 16:39 UTC (Sun) by farnz (subscriber, #17727) [Link]

The problem, of course, is that having chosen parameters that suit me, I can find criteria that explain my choices - while DJB has done his best to avoid suspicion, the possibility is still there, and the same applies to P-256 - after all, the NSA has enough compute power to try a bunch of seeds and find the ones that generate the right parameters.

Dual_EC_DRBG was, as you say, much more suspicious because the constants were unexplained magic numbers, but there is no way to take the choice of curve and field and demonstrate that they've not been nobbled; you can, of course, prove that the constants were fixed by finding the trick the constant setter is using to get broken curves.

Ultimately, though, this is all about the assumptions you need to make to prove the system secure assuming the keys can't be brute forced; for RSA, this is that primes can't be easily factored, and you've avoided keys that match the known weak keys. For ECC cryptography in all its forms, it's that the discrete logarithm problem can't be easily solved, and that the numbers you use to generate your finite field don't hide a weakness.

ssh-rsa deprecation

Posted May 31, 2020 16:42 UTC (Sun) by mpr22 (subscriber, #60784) [Link]

> this is that primes can't be easily factored

All primes can be easily factored ;) but I know what you meant.

ssh-rsa deprecation

Posted Jun 1, 2020 11:17 UTC (Mon) by jwilk (subscriber, #63328) [Link]

> for e.g. Ed25519, it seems that a 256-bit key really has a security level of 2^256

https://ed25519.cr.yp.to/ says 'This system has a 2^128 security target; […] The best attacks known actually cost more than 2^140 bit operations on average'

ssh-rsa deprecation

Posted Jun 3, 2020 15:08 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

Ssh8-62w

'But encrypting a secret using a fingerprint would not be possible, so this was a stupid idea.'

SSH doesn't do the thing you think is happening here anyway.

You probably figure, based on an explanation of PGP or SSL or something else from that era, that your client is picking a random session key and then encrypting it using the public key of the server - thus achieving implicit authentication, a bogus server wouldn't know the associated private key and can't decrypt the session key so it can't continue, thus if things work you've implicitly authenticated the server. You could do this with RSA but most public key schemes used today can't do it even if you wanted to, which we don't.

Instead in SSHv2 (the version from this century which we all use) like in modern TLS a key exchange algorithm agrees random session keys between both parties, and only *then* with everything safely encrypted, do they each prove who they are.

The server presents its public key, which your client can just memcmp() against that value in known_hosts, and then it proves that it knows the corresponding private key by signing a summary of the conversation so far with that key. Since your client knows the public key and also participated in the conversation so far it can verify that this is correct, even though it can't produce such a signature itself.

No encryption / decryption, just signatures and signature verification.

OpenSSH 8.3 released (and ssh-rsa deprecation notice)

Posted May 27, 2020 23:13 UTC (Wed) by flussence (subscriber, #85566) [Link]

OpenSSH 8.3 released (and ssh-rsa deprecation notice)

Posted May 28, 2020 2:20 UTC (Thu) by pabs (subscriber, #43278) [Link]

OpenSSH 8.3 released (and ssh-rsa deprecation notice)

Posted May 29, 2020 6:46 UTC (Fri) by flussence (subscriber, #85566) [Link]

OpenSSH 8.3 released (and ssh-rsa deprecation notice)

Posted May 29, 2020 6:48 UTC (Fri) by pabs (subscriber, #43278) [Link]

OpenSSH 8.3 released (and ssh-rsa deprecation notice)

Posted May 29, 2020 9:30 UTC (Fri) by flussence (subscriber, #85566) [Link]

I mean HTTPS certs on my end :)

They can mirror from git:// urls, but that feels wrong.

Version number

Posted May 28, 2020 15:47 UTC (Thu) by mat2 (guest, #100235) [Link]

OpenSSH 8.3 released (and ssh-rsa deprecation notice)

Posted May 28, 2020 19:41 UTC (Thu) by akkornel (subscriber, #75292) [Link]

(Mainly posting this to remind myself later)

Ssh 8gwifi

I was wondering exactly how SHA-1 was involved, so I looked it up!

> This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs.

Ssh 8.4

That is RFC 4253 (https://tools.ietf.org/html/rfc4253), page 14:

> The 'ssh-rsa' key format has the following specific encoding:
> …
> Signing and verifying using this key format is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.

Blargh…