Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA

From: Peter Gutmann <[email-masked]>
Date: Sat, 7 Nov 2015 03:46:03 +0000

denis bider <[email-masked]> writes:

>I was wondering how much SSH there is on embedded devices. I'm glad to hear
>you have that covered. :-)

A surprising amount, a lot of stuff that used to be done via a serial console
just got wrapped in SSH when the devices were Internet-enabled.  It means you
can keep using the same tools you've always used (TLS-protected web interfaces
may look cool on consumer devices, and there's some use coming in SCADA, but
you can't script them or manage them easily with standard tools).

The downside is that I've got workarounds for 15-year-old implementation bugs
still active in my code, because the software gets updated as infrequently as
the hardware, and the standards-conformance test for any SSH implementation is
"will putty connect to it?".

OK, drifting off-topic there :-).

Hmm, I wonder if it'd be worth doing a profile of SSH for embedded use?  It'd
certainly help clear some interop headaches, and give the SCADA folks a target
to aim for.

Peter.

---

From: denis bider <[email-masked]>
Date: Sat, 7 Nov 2015 02:22:14 +0000

Apologies for my ignorance about the embedded situation. That's interesting to know.

I was wondering how much SSH there is on embedded devices. I'm glad to hear you have that covered. :-)

I understand SHA-2 512 won't fit into P-256. It does fit into RSA, though, and I was figuring it would not be a problem for applications to support both hash types.

No problem if it's impractical, though. I appreciate the information!

I'll prepare new stuff hopefully tomorrow.

----- Original Message -----
From: Peter Gutmann 
Sent: Friday, November 6, 2015 18:51
To: denis bider 
Cc: [email-masked] 
Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA

denis bider <[email-masked]> writes:

>From my perspective, SHA-2 512 seems like the clear winner in the RSA
>situation, due to 64-bit CPUs being destined for ubiquity (already ubiquitous
>on desktops, a few years away on mobile), 

... and decades away on embedded.  Most of my users are running SSH on
embedded platforms, for which the presence of 64-bit is close to zero, and no
plan to move to that.  I probably have more SSH running on 16-bit embedded
than 64-bit embedded.

>why not have a larger hash output at no additional cost (it's embedded in the
>signature, anyway).

Not if you're using P-256 rather than RSA.  Only SHA-256 will work with P-256
which (again from the Mozilla discussion) is the most widely-used parameter
set, with P-521 (needed for -512) being barely used:

  lots of products can (and, it seems, are planning to, or already are)
  omitting support for P-521.
    (Comment from https://mozillians.org/en-US/u/briansmith/)

(You can truncate -512 to make it work with P-256, but I wouldn't want to take
any bets on how well-supported that will be in practice).

>However, if there are platforms where availability is a problem, then okay,
>let's have both versions. I'll update the draft to re-add rsa-sha2-256, and
>make that recommended, and -512 optional.

Thanks!

Peter.

---

From: [email-masked] (Niels Möller)
Date: Sun, 08 Nov 2015 19:30:45 +0100

> certainly help clear some interop headaches, and give the SCADA folks a target

I think we should try our best to have the set of REQUIRED algorithms
make sense on constrained embedded systems.

(Which might be a good reason to move forward with ed25519 and
curve25519. A few years ago I ported dropbear to a proprietary and
pretty slow embedded device, with only 8-bit arithmetic hardware. IIRC,
we constrained it to 1024-but RSA and group1 only. And after some pretty
serious but not exhaustive optimization (basically ripping out most of
libtomcrypt and replacing it with platform specific routines in assembly
and microcode), initial key exchange still took almost one minute. A
careful implementation of curve25519 and ed25519 would likely have
brought down the keyexchange time to something a bit more
user-friendly).

Regards
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 9 Nov 2015 00:35:59 +0000

Niels Möller <[email-masked]> writes:

>I think we should try our best to have the set of REQUIRED algorithms make
>sense on constrained embedded systems.

I've never really noticed any problem with the current set, typically time
isn't a big issue (as in, if ops take a few seconds then you just have to
accept that), the main one is memory use.  That is, users don't see it as a
big issue, there are always some requests about whether it can be made a bit
faster, but compatibility requirements with deployed code/devices almost
always outweigh that.

That's what a profile would have aimed at, a single well-defined set of
algorithms and mechanisms so you don't need to support every option available.
I actually had a go at this a while back:

https://www.cs.auckland.ac.nz/~pgut001/pubs/simplessh.txt

based on what I'd experienced in embedded environments.  The constraints
weren't the crypto used, it was cutting out the huge amount of unnecessary
(for the way it's used in embedded) complexity in the protocol.

>A few years ago I ported dropbear to a proprietary and pretty slow embedded
>device, with only 8-bit arithmetic hardware. 

You got SSH working on an 8-bit CPU?  How?

Peter.