Bug #2677

L15 Update

Added by robin.carey1 6 months ago. Updated 5 months ago.

Status:ClosedStart date:
Priority:HighDue date:
Assignee:-% Done:

100%

Category:-
Target version:3.9.x

Description

Dear DragonFlyBSD bugs,

Today I updated the L15 algorithm, available from:

http://www.leopard.uk.com/L15

The update is to the KSA (Key Scheduling Algorithm).

Perhaps DragonFlyBSD should consider updating their version,
as used for /dev/urandom ?

---

Also, I posted a bug report (some months ago now, I suspect),
which had to do with IBAA (as used for /dev/random), and specifically
relating to warming up the CSPRNG just before output in:

read_random()

As opposed to doing the warm-up after seeding the CSPRNG,
which unless I am mistaken, is what DragonFlyBSD does at the
moment.

I think there might also be one other update to L15 which I
mentioned on quite a while ago, which
I don't think was met with a response. That was to do with the
STATEINDEX_CARRY change that I made to L15.

---

In any case I am always happy to discuss these issues by E-mail ...

PS Good luck with the new 3.8.0 Release !!

--
Sincerely,

Robin Carey BSc


Related issues

Related to Bug #2601: IBAA and /dev/random Closed
Related to Bug #2472: L15 update Closed

History

#1 Updated by jorisgio 6 months ago

  • Priority changed from Normal to High
  • Target version set to 3.9.x

#2 Updated by alexh 6 months ago

My problem with this is that there seems to be little or no peer review of this algorithm. I'd rather see us move in a more mainstream direction, possibly using an RNG based on Salsa20 or ChaCha.

#3 Updated by zcrownover 6 months ago

  • Category set to Feature request

What about twofish, threefish or serpent?

#4 Updated by alexh 6 months ago

zcrownover wrote:
> What about twofish, threefish or serpent?

Those are block ciphers, not stream ciphers.

#5 Updated by alexh 6 months ago

  • Category deleted (Feature request)

#6 Updated by robin.carey1 6 months ago

Dear Alex,

Salsa20 or ChaCha are both more complicated algorithms (and so probably
slower aswell).
Also, I am not aware of any mathematical proofs/assurances of the security
of Salsa20 or ChaCha.
To be honest - I'm not really interested in Salsa20 or ChaCha.

L15 and IBAA are about as fast and simple/uncomplicated as it gets; The
core CSPRNG algorithm of
IBAA is approximately 4 lines of code. And the same is true of L15.

IBAA and L15 both have mathematical security assurances; indirection.

Probably another point worth making (which I believe has been made before)
is that IBAA produces
very high quality random data. The entry for ISAAC on Wikipedia (which
applies to IBAA) praises both
its speed and high-quality.

On 9 June 2014 08:52, <> wrote:

> Issue #2677 has been updated by alexh.
>
>
> My problem with this is that there seems to be little or no peer review of
> this algorithm. I'd rather see us move in a more mainstream direction,
> possibly using an RNG based on Salsa20 or ChaCha.
>
> ----------------------------------------
> Bug #2677: L15 Update
> http://bugs.dragonflybsd.org/issues/2677#change-12049
>
> * Author: robin.carey1
> * Status: New
> * Priority: High
> * Assignee:
> * Category:
> * Target version: 3.9.x
> ----------------------------------------
> Dear DragonFlyBSD bugs,
>
>
> Today I updated the L15 algorithm, available from:
>
> http://www.leopard.uk.com/L15
>
> The update is to the KSA (Key Scheduling Algorithm).
>
> Perhaps DragonFlyBSD should consider updating their version,
> as used for /dev/urandom ?
>
> ---
>
> Also, I posted a bug report (some months ago now, I suspect),
> which had to do with IBAA (as used for /dev/random), and specifically
> relating to warming up the CSPRNG just before output in:
>
> read_random()
>
> As opposed to doing the warm-up after seeding the CSPRNG,
> which unless I am mistaken, is what DragonFlyBSD does at the
> moment.
>
> I think there might also be one other update to L15 which I
> mentioned on quite a while ago, which
> I don't think was met with a response. That was to do with the
> STATEINDEX_CARRY change that I made to L15.
>
> ---
>
> In any case I am always happy to discuss these issues by E-mail ...
>
>
> PS Good luck with the new 3.8.0 Release !!
>
>
> --
> Sincerely,
>
> Robin Carey BSc
>
>
>
> --
> You have received this notification because you have either subscribed to
> it, or are involved in it.
> To change your notification preferences, please click here:
> http://bugs.dragonflybsd.org/my/account
>

--
Sincerely,

Robin Carey BSc

#7 Updated by robin.carey1 6 months ago

Dear Alex,

If you want to move to a more mainstream algorithm, consider using AES
(AES-CTR; AES/Counter mode).

AES is approved by NIST/NSA. I'm sure you must know that AES instructions
are built into some current CPUs
from Intel/AMD.

I don't think Salsa20 or ChaCha are approved by NIST/NSA.

On 9 June 2014 08:52, <> wrote:

> Issue #2677 has been updated by alexh.
>
>
> My problem with this is that there seems to be little or no peer review of
> this algorithm. I'd rather see us move in a more mainstream direction,
> possibly using an RNG based on Salsa20 or ChaCha.
>
> ----------------------------------------
> Bug #2677: L15 Update
> http://bugs.dragonflybsd.org/issues/2677#change-12049
>
> * Author: robin.carey1
> * Status: New
> * Priority: High
> * Assignee:
> * Category:
> * Target version: 3.9.x
> ----------------------------------------
> Dear DragonFlyBSD bugs,
>
>
> Today I updated the L15 algorithm, available from:
>
> http://www.leopard.uk.com/L15
>
> The update is to the KSA (Key Scheduling Algorithm).
>
> Perhaps DragonFlyBSD should consider updating their version,
> as used for /dev/urandom ?
>
> ---
>
> Also, I posted a bug report (some months ago now, I suspect),
> which had to do with IBAA (as used for /dev/random), and specifically
> relating to warming up the CSPRNG just before output in:
>
> read_random()
>
> As opposed to doing the warm-up after seeding the CSPRNG,
> which unless I am mistaken, is what DragonFlyBSD does at the
> moment.
>
> I think there might also be one other update to L15 which I
> mentioned on quite a while ago, which
> I don't think was met with a response. That was to do with the
> STATEINDEX_CARRY change that I made to L15.
>
> ---
>
> In any case I am always happy to discuss these issues by E-mail ...
>
>
> PS Good luck with the new 3.8.0 Release !!
>
>
> --
> Sincerely,
>
> Robin Carey BSc
>
>
>
> --
> You have received this notification because you have either subscribed to
> it, or are involved in it.
> To change your notification preferences, please click here:
> http://bugs.dragonflybsd.org/my/account
>

--
Sincerely,

Robin Carey BSc

#8 Updated by alexh 6 months ago

On 2014-06-09 11:25, wrote:
> Issue #2677 has been updated by robin.carey1.
>
> Salsa20 or ChaCha are both more complicated algorithms (and so probably
> slower aswell).

Both Salsa20 and ChaCha are designed to be high speed. I've not run any
benchmarks myself, but they generally come in at less than 10
cycles/byte, in the same ballpark as ISAAC.

> Also, I am not aware of any mathematical proofs/assurances of the
> security
> of Salsa20 or ChaCha.
> To be honest - I'm not really interested in Salsa20 or ChaCha.

That's fair enough that you are not interested. My point is that both of
them are well reviewed (as is ISAAC) - very much unlike L15. There is
not a single peer review of L15.

> L15 and IBAA are about as fast and simple/uncomplicated as it gets; The
> core CSPRNG algorithm of
> IBAA is approximately 4 lines of code. And the same is true of L15.

It's not about the lines of code, it's about the mathematical
correctness behind it. I'm not an expert, which is why I'd rather use an
algorithm that has been extensively reviewed instead of an algorithm
that has not been reviewed at all.

> IBAA and L15 both have mathematical security assurances; indirection.

As I said I'm no expert, but using indirection does not magically solve
all issues - there might very well still be weak states.

#9 Updated by alexh 6 months ago

On 2014-06-09 11:29, wrote:
> Issue #2677 has been updated by robin.carey1.

> If you want to move to a more mainstream algorithm, consider using AES
> (AES-CTR; AES/Counter mode).
>
> AES is approved by NIST/NSA. I'm sure you must know that AES
> instructions
> are built into some current CPUs
> from Intel/AMD.

I'm fully aware of the general availability of AES-related instructions
in many modern CPUs. However, not all do, and when they do not, AES is
rather expensive in terms of CPU cycles compared to stream ciphers such
as Salsa20 or ChaCha.

#10 Updated by jorisgio 6 months ago

  • Related to Bug #2601: IBAA and /dev/random added

#11 Updated by jorisgio 6 months ago

#12 Updated by dillon 5 months ago

Robin, could I get a diff of the two sets of changes you've made since our original incorporation? I can't tell what changed from looking at the C++ code vs my recollection of the code many months ago, and I don't have an old copy.

My thoughts on read_random() is to not put the warm-up there because it makes the performance of the read() path non-deterministic. Instead, we could put the warm-up after the interrupt re-seeding (that runs once a second), where the overhead is not critical.

-Matt

#13 Updated by dillon 5 months ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Closing. Made modifications as requested and also adjusted /dev/urandom and the sysctl random to use IBAA (which is what /dev/random uses), so they all use IBAA now and nothing uses L15. These changes will make it into the 3.8.1 roll on Monday June 16th 2014.

In the near future we will run with two independent algorithms and xor their streams together. We are discussing this now. 3.8.1 will likely roll with just IBAA but if we get the second algorithm in place in the next few weeks we will MFC it to the release branch.

-Matt

Also available in: Atom PDF