some questions on OpenSSH alogs

Christian Weisgerber naddy at mips.inka.de
Wed Oct 22 07:43:28 EST 2014


On 2014-10-19, Christoph Anton Mitterer <calestyo at scientia.net> wrote:

> Mhh sure,... but is there any advantage (apart from performance and ease
> of implementation), of using an AE cipher instead of an encrypting-only
> cipher in combination with a MAC?

Nope.

> So for ED25519 and ECDH with the NIST curves... all the DH parameters
> and sizes are fixed anyway, right?

Right.  This is a good thing.  It means there is no need or opportunity
for people to compulsively fiddle with parameters and shoot themselves
in the foot.

>> Poly1305, U/VMAC, and GMAC all run the data through a noncryptographic
>> hash and encrypt the result with AES.
> How important is the size there? I mean umac-128 and especially -64
> sounds little in comparison to the hash sizes of e.g. sha2-512 with
> HMAC.

A priori, the probability of a successful forgery with an n-bit
authentication tag is 1/2^n.  The question is if attack strategies
can improve on this.  RFC4418 gives a boundary of 1/2^60 for UMAC-64.

An important consideration is that the SSH protocol severely limits
the number of possible forgery attempts: If MAC verification fails,
the session is killed.  Attacks that require a substantial number
of verification queries, as discussed for instance here
http://link.springer.com/chapter/10.1007%2F978-3-540-85174-5_9
are not applicable.

>> Strength-wise, Curse25519 compares to NIST-P256, so it depends how
>> you feel about the NIST curves.
> So you said it uses SHA2 as well,... is there going to be an alternative
> that uses Keccak?

The Curve25519 key exchange and Ed25519 signing could be replaced
with analogous schemes that swap SHA2 for SHA3, yes.  I doubt anybody
will bother until SHA2 is shown to be weak.

> Or one which is, from the key size POV, more int eh P521 range?

Curve25519/Ed25519 are good enough.

Let's regain some perspective here: The purpose of SSH is to provide
mutually authenticated and confidential remote login/command execution/
data transfer.  It is not intended to be a comprehensive collection
of cryptographic algorithms.  It is supposed to just work and not
require tweaking and magic incantations.

"Buttons are for idiots", "knobs are for knobs", etc.

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de


More information about the openssh-unix-dev mailing list