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