Follow @Openwall on Twitter for new release announcements and other news
[<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.