DragonFlyBSD

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.

zcrownover wrote:

What about twofish, threefish or serpent?

Those are block ciphers, not stream ciphers.

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, <bugtracker-admin@leaf.dragonflybsd.org> 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 bugs@dragonflybsd.org 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

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, <bugtracker-admin@leaf.dragonflybsd.org> 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 bugs@dragonflybsd.org 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

On 2014-06-09 11:25, bugtracker-admin@leaf.dragonflybsd.org 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.

On 2014-06-09 11:29, bugtracker-admin@leaf.dragonflybsd.org 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.

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