Re: AEAD in ssh

[denis bider <ietf-ssh3%denisbider.com@localhost>]

I can appreciate these concerns. I understand our markets are very different. With our SSH Server and Client, we don't target anything below the hardware it takes to run Windows x86 or x64, desktop or server. We can expect at LEAST hardware equivalent to an Amazon micro instance. This is of a larger size today, than it was years ago. What is called "micro" now was called "small".

Yesterday, Raspberry Pi 3 came out. It still costs $35, and now has a 1.2 GHz 64-bit processor, integrated Bluetooth, and Wi-Fi:

https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/

It may be that Moore's law is coming to an end, at the high end of the scale. But miniaturization and efficiency are not. For devices in lower price ranges, performance per $ will continue to improve.

It seems to me the only way you have a computing resource problem is if your customers' stinginess increases in tandem with miniaturization. For example, maybe a number of years ago your customers were willing to pay $10 per gadget. Now, perhaps they're willing to pay only $1, while keeping performance the same. Is that the trend you see?

If people are increasingly trying to put secure protocols on smaller devices - yesterday $10; today $1; tomorrow a needle head that costs 10 cents - it seems to me that the needs of this market segment might indeed be best served by some restricted subset of existing protocols, or a protocol designed specifically for that.

From my position, it's not a problem to support an algorithm that uses unencrypted lengths, so it can be compatible with a 10 cent implementation the size of a needle head.

I don't want your 10 cent implementation to constrain me in what I can provide to my users, however. Maybe you can't afford a fixed-bandwidth terminal session. However, it seems like an excellent fit to provide privacy for interactive administration of a server in a data center.


----- Original Message -----
From: Peter Gutmann
Sent: Sunday, February 28, 2016 20:33
To: denis bider
Cc: Niels Möller ; Bryan Ford ; Mark D. Baushke ; Stephen Farrell ; Watson Ladd ; Daniel Migault ; Curdle Chairs ; ietf-ssh%NetBSD.org@localhost
Subject: RE: AEAD in ssh

denis bider <ietf-ssh3%denisbider.com@localhost> writes:

>If I restrict myself to send the same amount of data, at regular intervals,
>independent of my packet queue; if I pick up packets from my queue if they
>are any, and send IGNORE messages otherwise; then this prevents keystroke
>analysis if done in 10 second bursts; and if I keep it up, it masks
>everything done on the connection.

Well, you *think* it does, in the same way that people once thought traffic
padding would mask everything on the connection (I'm assuming they did, given
that it's the only anti-TA measure present in both TLS and SSH).  Show me
empirical data of it resisting attacks of the kind described in Peekaboo and
other papers...

>You crack this joke, just after I pointed out that this costs 1 Mbps or less,
>whereas Netflix uses 3 - 5 Mbps. This is when Google Fiber is rolling out in
>the US, and we can expect 1 Gbps speeds to be normal in 15 years (if backward
>thinking people don't stop it).

Yeah, and that's part of the way-too-common thinking that in the future we'll
all have infinite CPU, infinite RAM, and infinite bandwidth that leads to
people creating totally unworkable Rube-goldberg contraptions of crypto
protocols.  A few days ago I got to review two proposed ISO standards for IoT
in which a bunch of networking engineers tried to invent some sort of crypto
mechanism that makes WEP look like a model of good design, because both TLS
and SSH are far too bloated to work for them.  It's not their fault, they're
networking engineers and shouldn't be expected to have to do this, but the
crypto community just assumes infinite resources and goes from there.  I've
got users who don't want to move from SHA-1 to SHA-256 because of the extra
size introduced by the larger MACs, and you're telling me that we can all
dream of 1GBPs in the near future...

Peter.