Yegor Ievlev <koops1997@xxxxxxxxx> writes:
> I'm not sure if collision resistance is required for DH key
> derivation, but generally, SHA-1 is on its way out. If it's possible
> (if there's not a very large percentage of servers that do not support
> anything newer), it should be disabled.
Perhaps, but doing so will be the final break in dealing with devices
that have SSH, but no path to really upgrade the implementation. Just
putting it at the end of the negotation list will do almoast as well.
Both diffie-hellman-group1-sha1 (which is defined in RFC 2412 section
E.2 as 'Well-Known Group 2: A 1024 bit prime', so the name 'group1' has
always been a bit of a misrepresentation) and
diffie-hellman-group14-sha1 were specified in RFC 4253 as a REQUIRED to
implement key exchange.
By default you may choose to not include them in your key exchange
lists, but it would perhaps be better if you just put them at the end of
the selections.
Of course, the Mandatory To Implement (MTI) algorithms for SSH are
getting a bit long in the tooth now.
Key Exchange Methods:
diffie-hellman-group1-sha1 REQUIRED
diffie-hellman-group14-sha1 REQUIRED
Public Key:
ssh-dss REQUIRED sign - Raw DSS Key (with SHA1 hashing of the key)
MAC Algorithm:
hmac-sha1 REQUIRED - HMAC-SHA1 (digest length = key length = 20)
Cipher:
3des-cbc REQUIRED - three-key 3DES in CBC mode
Compression:
none REQUIRED - no compression
I personally believe we can and should deprecate
diffie-hellman-group1-sha1, but think that diffie-hellman-group14-sha1
should just be stuck to the end of the negotation list.
Note: If the device needs to pass FIPS 140-2 certification or some kind
of Common Criterial Evalution, then there will be a requirement to NOT
have ssh-dss or diffie-hellman-group14-sha1 in the negotiations. I also
expect that 3des-cbc will be on the list of non-approved algorithms
before too long.
We have lots of choices for public key cryptography: FFC = Finite Field
Cryptography (Diffie-Hellman (DH) and Digital Signature Algorith (DSA)),
IFC = Integer Factorization Cryptography (RSA), ECC = Elliptic Curve
Cryptography (Elliptic Curve DSA (ECDSA), Elliptic Curve Diffie-Hellman
(ECDH), Edwards-Curve Digital Signature Algorithm EcDSA).
None of these are secure from Post Quantum Cryptography (PQC).
My personal preferences are, you will note that I usually DO still put
the MTI arguments at the end of my lists.
KEX:
diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,
curve25519-sha256@xxxxxxxxxx,diffie-hellman-group14-sha256,
diffie-hellman-group14-sha1
Public key (per RFC 8332 and 8308 - with 3072-bit RSA keysize):
rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ssh-rsa,
ecdsa-sha2-nistp256,ssh-dss
Ciphers:
aes256-gcm@xxxxxxxxxxx,chacha20-poly1305@xxxxxxxxxxx,
aes128-gcm@xxxxxxxxxxx,aes256-ctr,aes256-cbc,aes128-ctr,aes128-cbc,
3des-ctr,3des-cbc
MAC:
hmac-sha2-512-etm@xxxxxxxxxxx,hmac-sha2-512,hmac-sha2-256,hmac-sha1
Compression:
none
Note: for diffie-hellman-group-exchange-sha256 a la RFC 4419/8270
provide that g is a proper generator of a q-ordered subgroup which is
not mandated by the RFCs.
Note: I tend to favor sha2-512 over sha2-256 where possible as it is
usually faster on 64-bit processors and in hardware accelarators. I
would probably use sha2-384 if it were more generally available as more
of the internal state of the internal SHA engine bits are kept secret.
-- Mark
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
