Poly1305 on sparc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Poly1305 on sparc

Christian Weisgerber
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
SPARC V7.

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.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Poly1305 on sparc

Theo de Raadt
>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
>SPARC V7.
>
>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 :-)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Poly1305 on sparc

Christian Weisgerber
On 2015-03-27, Theo de Raadt <[hidden email]> wrote:

>>> 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
disproportionately slower.

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,
thanks.)

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Poly1305 on sparc

Miod Vallat
> That's all theory on my part.  I don't have a sparc to test.  (No,
> thanks.)

You could port `tme' and check. It might be faster than the real thing
on today's hardware.

Loading...