[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150113184914.GA17235@openwall.com>
Date: Tue, 13 Jan 2015 21:49:14 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PRINCE
On Tue, Jan 13, 2015 at 07:21:47PM +0100, magnum wrote:
> FWIW I did a quick and dirty test today with dropping GMP and using
> gcc's __uint128_t extension just to see what performance it would get.
> That was trivial and the boost was pretty significant: 33% faster.
Great.
Is 128-bit guaranteed to be large enough not to overflow in PRINCE?
> Internally gcc obviously does this using pairs of 64-bit words. I guess
> we should add 128/64-bit versions of the 64/32 stuff in math.h instead,
> for portability. Since I can use __uint128_t for testing I can probably
> work out how to write the functions given enough trial and error :-)
We may. This should be straightforward.
> Unless... Solar, you don't happen to have 128/64 code readily available?
No.
As an alternative, we could have 64-bit saturating math - just detect
overflow and set the result to the max value if so. This is trivial for
addition, but unfortunately is slow for multiplication - we'd have to
divide to check if there was overflow, which is very slow. So perhaps
not a good idea for speed reasons.
As a maybe better alternative, what about "double"? Have you tried?
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
