>On 2015-03-24, Damien Miller <[hidden email]> wrote:
>> CVSROOT: /cvs
>> Module name: src
>> Changes by: [hidden email] 2015/03/24 03:17:21
>> Modified files:
>> usr.bin/ssh : myproposal.h
>> Log message:
>> promote [hidden email] to be the default cipher;
>> ok markus
>FWIW, Poly1305 uses _a lot_ of multiplications. I expect it to
>perform poorly with SPARC V7 code.
>In fact, UMAC from the previous default of aes128-ctr +
>[hidden email] already uses quite a lot of multiplications,
>although fewer than Poly1305, and I suspect it underperforms with
>People who find scp throughput very slow on sparc may want to
>experiment with switching to aes128-ctr plus one of the
>hmac-*-[hidden email] MACs.
Well, I don't think the world will fall over as a result. Slow
machines becoming slower, nothing else new :-)
>>> promote [hidden email] to be the default cipher;
>>FWIW, Poly1305 uses _a lot_ of multiplications. I expect it to
>>perform poorly with SPARC V7 code.
> Well, I don't think the world will fall over as a result.
Frankly, I think sparc is dead and support should be dropped. But
since I can't dictate how people spend their time, I thought I'd
mention this issue for the very few who care. Don't get me wrong,
I fully support the switch to [hidden email].
> Slow machines becoming slower, nothing else new :-)
Sure, but I think this is an instance of slow machines becoming
Poly1305 may be mathematically elegant, but djb's propaganda about
its performance is to be taken with a lump of salt. Unsurprisingly
it's geared towards modern CPUs. For Poly1305 to perform well, you
want a CPU that can execute several multiplications in parallel.
A single multiplier is already a bottleneck, and having no hardware
multiplication at all, like SPARC V7, must be really bad.
That's all theory on my part. I don't have a sparc to test. (No,