Pavel Machek wrote:
> To play devil's advocate, does RNG subsystem need to evolve? Its task
> is to get random numbers. Does it fail at the task?
>
> Problem is, random subsystem is hard to verify, and big rewrite is
> likely to cause security problems...
Parts of the problem, though, are dead e
Bhat, Jayalakshmi Manjunath wrote:
> We are executing a simple ping test on our device in transport mode.
I wrote this 20 years ago. Does it help?
https://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/faq.html#cantping
Eric Curtin wrote:
> Hope I'm not bothering you. I'm looking for a masters thesis idea, ...
Here's a report claiming 70% of security bugs involve memory errors.
https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/
Build a tool to find or fix those?
Another repo
Eric Curtin wrote:
> Hope I'm not bothering you. I'm looking for a masters thesis idea, ...
> I'm really liking this
> new QUIC (UDP) protocol as an alternative to TCP over TLS. And with
> the growth of new modern secure protocols like Wireguard. I was
> wondering, would it be an idea to do a mo
First off, it is not clear we should implement WEP at all since it is
fatally flawed. This has been known for about a decade, there have
been at least two better algorithms added to the standards, & the only
reason anyone would need WEP today would be to connect to an old
router in an obviously ins
Pascal Van Leeuwen wrote:
> ... the proper way to do this is not by
> doing an #ifdef but by using a regular if with IS_ENABLED like so:
>
> if (IS_ENABLED(CONFIG_PCI)) {}
See also:
http://doc.cat-v.org/henry_spencer/ifdef_considered_harmful
On Tue, Sep 18, 2018 at 7:03 PM John Denker wrote:
> > Is a fix that only deals with a subset of the problem worth
> > considering? Just patch the VM support code so that any time a VM is
> > either booted or re-started after a save, the host system drops in
> > some entropy, ...
>
> Good solutio
Getting the random driver well initialised early enough is a hard
problem, at least on some machines.
Solutions have been proposed by various people. If I understand them
right, Ted Ts'o suggests modifying the boot loader to provide some
entropy & John Denker suggests that every machine should be
Theodore Y. Ts'o wrote:
> For those people who are super paranoid and want a "true
> random number generator" (and the meaning of that is hazy) because a
> CRNG is Not Enough, my recommendation these days is that they get
> something like an open hardware RNG solution, such as ChaosKey from
> Al
On Tue, Jul 17, 2018 at 9:51 PM, Theodore Y. Ts'o wrote:
> On Tue, Jul 17, 2018 at 09:43:44PM -0400, Theodore Ts'o wrote:
>> This gives the user building their own kernel (or a Linux
>> distribution) the option of deciding whether or not to trust the CPU's
>> hardware random number generator (e.g
I shortened the cc list radically. If the discussion continues, it may
be a good idea to add people back. I added John Gilmore since I cite
one of his posts below.
Jonathan Cameron wrote:
> On behalf of Huawei, I am looking into options to foster a wider community
> around the various ongoing pr
On Tue, Aug 22, 2017 at 12:14 PM, Tudor Ambarus
wrote:
> Hi, Herbert,
>
> On 02/02/2017 03:57 PM, Herbert Xu wrote:
>>
>> Yes but RSA had an in-kernel user in the form of module signature
>> verification. We don't add algorithms to the kernel without
>> actual users. So this patch-set needs to c
Showing only the key parts of the message:
> From: John Gilmore
An exceedingly knowledgeable guy, one we should probably take seriously.
https://en.wikipedia.org/wiki/John_Gilmore_(activist)
> Most hardware crypto accelerators are useless, ...
> ... you might as well have
> just computed the an
To me it seems obvious that if the hardware provides a real RNG, that
should be used to feed random(4). This solves a genuine problem and,
even if calls to the hardware are expensive, overall overhead will not
be high because random(4) does not need huge amounts of input.
I'm much less certain har
Cleaning up old email, ran across this post & it seemed to me it might
be relevant here:
-- Forwarded message --
From: John Gilmore
Date: Thu, Jul 21, 2011 at 9:53 PM
Subject: Re: [Freedombox-discuss] Hardware Crypto
To: "erik.e.har...@gmail.com"
Cc: freedombox list
> Can some
Sandy Harris wrote:
> The biggest problem with random(4) is that you cannot generate good
> output without a good seed & just after boot, ...
>
> The only really good solution I know of is to find a way to provide a
> chunk of randomness early in the boot process. Joh
On Tue, Jul 18, 2017 at 5:08 PM, Theodore Ts'o wrote:
> I've been trying to take the best features and suggestions from your
> proposal and integrating them into /dev/random already.
A good approach.
> Things that I've chosen not take is basically because I disbelieve
> that the Jitter RNG is v
On Tue, Jun 20, 2017 at 5:49 AM, Jeffrey Walton wrote:
> On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o wrote:
>> On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote:
>>> > Suppressing all messages for all configurations cast a wider net than
>>> > necessary. Configurations that c
iver at
https://github.com/sandy-harris/maxwell The only kernel-space code I
know of is Stephan's.
If the claim that such calls give entropy is accepted (which I think
it should be) then if we get one bit per call, need 100 or so bits &
space the calls 100 ns apart, loading up a decent chunk of start
The only sensible & general solution for the initialisation problem
that I have seen is John Denker's.
http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image
If I read that right, it would require only minor kernel changes &
none to the API Ted & others are worrying about. It would be s
On Sat, Apr 22, 2017 at 3:54 PM, Sandy Harris wrote:
> In the FreeS/WAN project, back around the turn of the century,
> we refused to implement several things required by the RFCs
Link to documentation:
http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/compat.html#dropped
On Sat, Apr 22, 2017 at 2:56 AM, Stephan Müller wrote:
> Am Freitag, 21. April 2017, 17:25:41 CEST schrieb Stephan Müller:
> Just for the records: for FIPS 140-2 rules, cipher_null is to be interpreted
> as a memcpy on SGLs. Thus it is no cipher even though it sounds like one.
>
> cipher_null is
Add Ted T'so to cc list. Shouldn't he be included on anything affecting
the random(4) driver?
On Tue, Oct 18, 2016 at 8:34 AM, Corentin Labbe
wrote:
> From: LABBE Corentin
>
> The Security System have a PRNG.
> This patch add support for it as an hwrng.
Which is it? A PRNG & a HW RNG are quite
On Wed, Nov 2, 2016 at 4:09 PM, Herbert Xu wrote:
> On Wed, Nov 02, 2016 at 06:58:10PM +0100, Jason A. Donenfeld wrote:
>> On MIPS chips commonly found in inexpensive routers, this makes a big
>> difference in performance.
>>
>> Signed-off-by: Jason A. Donenfeld
>
> Can you give some numbers ple
on is at:
https://github.com/sandy-harris/maxwell
A small (< 700 lines) daemon that gets entropy from timer imprecision
and variations in time for arithmetic (cache misses, interrupts, etc.)
and pumps it into /dev/random. Make it the first userspace program
started and all should be covere
Version 2 of my maxwell(8) rng is now at:
https://github.com/sandy-harris/maxwell
It is a fairly simple program to gather entropy from timer
fluctuations & feed results into the Linux random(4) device. Small
--only 600 lines so reasonably easy to audit -- cheap & effective.
It has not
On Mon, Jul 18, 2016 at 3:14 AM, Herbert Xu wrote:
> Stephan Mueller wrote:
>> This patch adds the ability to register templates for RNGs. RNGs are
>> "meta" mechanisms using raw cipher primitives. Thus, RNGs can now be
>> implemented as templates to allow the complete flexibility the kernel
>>
On Sun, Jun 19, 2016 at 3:36 PM, Pavel Machek wrote:
>> The following patch set provides a different approach to /dev/random ...
>
> Dunno. It is very similar to existing rng, AFAICT.
I do not think so. A lot of the basic principles are the same of course,
but Stephan is suggesting some real cha
David Jaša wrote:
>
> BTW when looking at an old BSI's issue with Linux urandom that Jarod
> Wilson tried to solve with this series:
> https://www.spinics.net/lists/linux-crypto/msg06113.html
> I was thinking:
> 1) wouldn't it help for large urandom consumers if kernel created a DRBG
> instance f
On Fri, May 27, 2016 at 2:30 PM, Stephan Mueller wrote:
> This document describes extractors. Those extractors are intended to combine
> *independent* sources with weak entropy.
>
> None of our sources we have in add_*_randomness are independent.
No, but it would be easy to get two independent s
A theoretical paper on getting provably excellent randomness from two
relatively weak input sources.
https://www.sciencenews.org/article/new-technique-produces-real-randomness
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kerne
On Thu, May 26, 2016 at 2:49 PM, Stephan Mueller wrote:
> Then, the use of the DRBG offers users to choose between a Hash/HMAC and CTR
> implementation to suit their needs. The DRBG code is agnostic of the
> underlying cipher. So, you could even use Blowfish instead of AES or whirlpool
> instead
Stephan Mueller wrote:
> for the DRBG and the LRNG work I am doing, I also test the speed of the DRBG.
> The DRBG can be considered as a form of block chaining mode on top of a raw
> cipher.
>
> What I am wondering is that when encrypting 256 16 byte blocks, I get a speed
> of about 170 MB/s with
On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote:
> Instead of arguing over who's "sane" or "insane", can we come up with
> a agreed upon set of tests, and a set of compiler and compiler
> versions ...
I completely fail to see why tests or compiler versions should be
part of the discussion.
On Mon, Apr 25, 2016 at 12:06 PM, Andi Kleen wrote:
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
I did not write that. I think Andi is quoting himself here, not
Stephan has recently proposed some extensive changes to this driver,
and I proposed a quite different set earlier. My set can be found at:
https://github.com/sandy-harris
This post tries to find the bits of both proposals that seem clearly
worth doing and entail neither large implementation
gt; - Ted
Jitter, havege and my maxwell(8) all claim to get entropy from
variations in timing of simple calculations, and the docs for
all three give arguments that there really is some entropy
there.
Some of those arguments are quite strong. Mine are in
Salvatore Benedetto wrote:
>> > > > +static int dh_check_params_length(unsigned int p_len)
>> > > > +{
>> > > > + switch (p_len) {
>> > > > + case 768:
>> > > > + case 1024:
>> > > > + case 1536:
>> > > > + case 2048:
>> > > > + case 3072:
>> > > > + case
This set of patches, plus some later ones that simplify the
code and get rid of one major bug are now at:
https://github.com/sandy-harris
Directory for these changes is random.gcm
An out-of-kernel test program for an older version
is in random.test
On Sat, Nov 7, 2015 at 1:50 PM, Sandy Harris
This article is old (turn of the century) but it may have numbers
worth comparing to
http://www.freeswan.org/freeswan_trees/CURRENT-TREE/doc/performance.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordo
On Wed, Nov 18, 2015 at 12:10 AM, Ismail Kizir wrote:
> I've developed a new encryption algorithm, which dynamically changes
> the key according to plaintext and practically impossible to break.
There is a very long history of crypto whose author considers is
secure being quickly broken. This ha
e comments on both
the rationale for this approach & the details of my
implementation.
random_gcm.c is not close to being a finished
product, in particular my code is not yet well
integrated with existing driver code.
Most of the code was developed and has been
fairly well tested outside th
On Sat, Nov 7, 2015 at 12:01 PM, Jason Cooper wrote:
> On Sat, Nov 07, 2015 at 09:30:36AM -0500, Sandy Harris wrote:
>> Signed-off-by: Sandy Harris
>> ---
>> .gitignore | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/.gitignore b/.git
Signed-off-by: Sandy Harris
---
drivers/char/Kconfig | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index a043107..0e0e6b5 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -603,5 +603,28 @@ config TILE_SROM
Signed-off-by: Sandy Harris
---
drivers/char/Makefile | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index d8a7579..7d095e5 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -2,7 +2,30
Signed-off-by: Sandy Harris
---
scripts/gen_random.c | 260 +++
1 file changed, 260 insertions(+)
create mode 100644 scripts/gen_random.c
diff --git a/scripts/gen_random.c b/scripts/gen_random.c
new file mode 100644
index 000..07b447f
Signed-off-by: Sandy Harris
---
Kbuild | 21 +
scripts/Makefile | 1 +
2 files changed, 22 insertions(+)
diff --git a/Kbuild b/Kbuild
index f55cefd..494c665 100644
--- a/Kbuild
+++ b/Kbuild
@@ -5,6 +5,7 @@
# 2) Generate timeconst.h
# 3) Generate asm-offsets.h
Signed-off-by: Sandy Harris
---
.gitignore | 3 +++
1 file changed, 3 insertions(+)
diff --git a/.gitignore b/.gitignore
index fd3a355..dd80bfd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -112,3 +112,6 @@ all.config
# Kdevelop4
*.kdev4
+
+certs/x509_certificate_list
+scripts/gen_random
Signed-off-by: Sandy Harris
---
drivers/char/random.c | 50 ++
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d0da5d8..e222e0f 100644
--- a/drivers/char/random.c
+++ b/drivers/char
On Thu, Nov 5, 2015 at 8:17 PM, Zain Wang wrote:
> The names registered are:
> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
> You can alloc tags above in your case.
Why on Earth are you allowing DES? Here's a reference from around the
turn of the century on why the FreeS/WA
On Wed, Oct 21, 2015 at 1:06 PM, wrote:
> I've only looked at it briefly, but I have a question.. Are you trying to
> use the GCM Galois multiply as an entropy extractor?
Yes, the basic idea is to use a series of GCM multiplies over the pool
data to replace the hashing of that data in the curre
I've just created github repositories for two projects:
https://github.com/sandy-harris/random.test
Test program for things I want to add to the Linux random(4) driver. I
am proposing a fairly radical rewrite. This gives an executable test
program for my new code, not a driver.
On Mon, Jul 27, 2015 at 7:01 AM, Stephan Mueller wrote:
> This one does not look good for a claim that the RNG produces white noise. An
> RNG that is wired up to /dev/hwrng should produce white noise. Either by
> having an appropriate noise source or by conditioning the output of the noise
> sour
On Tue, Jun 16, 2015 at 5:59 AM, Boris Brezillon
wrote:
> Add support for DES operations.
Why on Earth should we do that? DES is demonstrably insecure. The only
possible excuse for allowing it anywhere in a modern code base is that
you need it to implement triple DES, and even that should by now
On Mon, May 18, 2015 at 6:58 PM, Herbert Xu wrote:
> Stephan Mueller wrote:
>>
>> I hear more and more discussions about recommendations to use AES 256 and not
>> AES 128.
Or perhaps other ciphers with 256-bit keys. Salsa, ChaCha and several of
the Caesar candidates support those.
>> These kin
sri sowj wrote:
> I have seen multiple open source drivers for AES(CTR) mode for
> different Crypto Hardware Engines, I was not really sure on
> countersize,nonce etc.
> Please can any one provide some info on the following
Not what you asked for, but in case it is useful here is the counter
man
On Sun, Nov 9, 2014 at 5:33 PM, Stephan Mueller wrote:
> while working on the AF_ALG interface, I saw no active zeroizations of memory
> that may hold sensitive data that is maintained outside the kernel crypto API
> cipher handles. ...
> I think I found the location for the first one: hash_sock
I have started a thread about this on the gcc help mailing list
https://gcc.gnu.org/ml/gcc-help/2014-10/msg00047.html
We might consider replacinging memzero_explicit with memset_s() since
that is in the C!! standard, albeit I think as optional. IBM, Apple,
NetBSD, ... have that.
https://mail-index
On Mon, Oct 6, 2014 at 1:44 PM, Jason Cooper wrote:
> On Sat, Oct 04, 2014 at 11:09:40PM -0400, Sandy Harris wrote:
>> There was recently a patch to the random driver to replace memset()
>> because, according to the submitter, gcc sometimes optimises memset()
>> away ..
On Mon, Oct 6, 2014 at 1:44 PM, Jason Cooper wrote:
> On Sat, Oct 04, 2014 at 11:09:40PM -0400, Sandy Harris wrote:
>> There was recently a patch to the random driver to replace memset()
>> because, according to the submitter, gcc sometimes optimises memset()
>> away w
There was recently a patch to the random driver to replace memset()
because, according to the submitter, gcc sometimes optimises memset()
away which might leave data unnecessarily exposed. The solution
suggested was a function called memzero_explicit(). There was a fair
bit of discussion and the pa
I have started a thread with the above title on Perry's crypto list. Archive at:
http://www.metzdowd.com/pipermail/cryptography/2014-September/022795.html
First message was:
I have some experimental code to replace parts of random.c It is not
finished but far enough along to seek comment. It does
On Tue, Jul 1, 2014 at 7:14 AM, Corentin LABBE
wrote:
> I am writing the PRNG driver for the Allwinner Security System SoC A20.
The datasheet my search turned up (v1, Feb. 2013) just says: "160-bit
hardware PRNG with 192-bit seed" and gives no other details. Do you
have more info, perhaps from
On Thu, Apr 24, 2014 at 9:34 AM, leroy christophe
wrote:
> I'm progressing well on the SEC1 implementation. I now have HASH (non HMAC)
> , DES and AES working properly.
Why DES? More than a decade ago, the first Linux IPsec implementation
refused to do single DES because it was known to be insec
Theodore Ts'o wrote:
> Fundamentally, what worries me about this scheme (actually, causes the
> hair on the back of my neck to rise up on end) is this statement in
> your documentation[1]:
>
>When looking at the sequence of time deltas gathered
>during testing [D] , no pattern can be dete
Stephan Mueller wrote:
> [quoting me]
>> ...your code is basically, with 64-bit x:
>>
>> for( i=0, x = 0 ; i < 64; i++, x =rotl(x) )
>>x |= bit()
>
> Why not declare some 64-bit constant C with a significant
>>number of bits set and do this:
>>
>> for( i=0, x = 0 ; i < 64; i++, x =ro
On Mon, Oct 14, 2013 at 11:26 AM, Stephan Mueller wrote:
>>Why not declare some 64-bit constant C with a significant
>
> Which constant would you take? The CRC twist values? The SHA-1 initial
> values? Or the first few from SHA-256?
The only essential requirement is that it not be something stup
On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller wrote:
> Another thing: when you start adding whitening functions, other people
> are starting (and did -- thus I added section 4.3 to my documentation)
> to complain that you hide your weaknesses behind the whiteners. I simply
> want to counter t
On Mon, Oct 14, 2013 at 9:38 AM, Sandy Harris wrote:
> Stephan Mueller wrote:
>> Can you please help me understand why you think that a whitening
>> function (cryptographic or not) is needed in the case of the CPU Jitter
>> RNG, provided that I can show that each individua
Stephan Mueller wrote:
>>Paper has:
>>
>>" the time delta is partitioned into chunks of 1 bit starting at the
>>lowest bit " The 64 1 bit chunks of the time value are XORed with
>>each other to " form a 1 bit value.
>>
>>As I read that, you are just taking the parity. Why not use that
>>simp
On Fri, Oct 11, 2013 at 2:38 PM, Stephan Mueller wrote:
I like the basic idea. Here I'm alternately reading the email and the
page you link to & commenting on both.
A nitpick in the paper is that you cite RFC 1750. That was superceded
some years back by RFC 4086
http://tools.ietf.org/html/rfc408
Stephan Mueller wrote:
> Ted is right that the non-deterministic behavior is caused by the OS
> due to its complexity. ...
>> > For VM's, it means we should definitely use
>> > paravirtualization to get randomness from the host OS.
>> ...
>
> That is already in place at least with KVM and Xen a
On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o wrote:
> I continue to be suspicious about claims that userspace timing
> measurements are measuring anything other than OS behaviour.
Yes, but they do seem to contain some entropy. See links in the
original post of this thread, the havege stuff and
I very much like the basic notion here. The existing random(4) driver
may not get enough entropy in a VM or on a device like a Linux router
and I think work such as yours or HAVEGE
(http://www.irisa.fr/caps/projects/hipsor/) are important research.
The paper by McGuire et al of "Analysis of inheren
On Thu, Feb 21, 2013 at 9:17 AM, Stephan Mueller wrote:
> There is no state between calls. Of course, you need a scratchpad to do
> calculations.
But in general you need a buffer. It is quite easy to construct scenarios where
several K bits of entropy are needed very -- for example, reboot an IP
On Sun, Feb 10, 2013 at 2:32 PM, Stephan Mueller wrote:
> On 10.02.2013 19:50:02, +0100, Theodore Ts'o wrote:
> Given all your doubts on the high-precision timer, how can you
> reasonably state that the Linux kernel RNG is good then?
>
> The data from add_timer_randomness the kernel feeds into
On Sun, Feb 10, 2013 at 1:50 PM, Theodore Ts'o wrote:
> On Sun, Feb 10, 2013 at 01:46:18PM +0100, Stephan Mueller wrote:
>>
>> However, the CPU has timing jitter in the execution of instruction. And
>> I try to harvest that jitter. The good thing is that this jitter is
>> always present and can b
On Wed, Jun 27, 2012 at 12:13 AM, Sebastian Andrzej Siewior
wrote:
> Since commit ce6dd368 ("crypto: arc4 - improve performance by adding
> ecb(arc4)) we need to pull in a blkcipher.
>
> |ERROR: "crypto_blkcipher_type" [crypto/arc4.ko] undefined!
> |ERROR: "blkcipher_walk_done" [crypto/arc4.ko] un
On Thu, Sep 29, 2011 at 2:46 PM, Sandy Harris wrote:
> I have been thinking about how random(4) might be redesigned ...
>
> ... make the input
> pool use Skein (or another SHA-3 candidate) and the output pools a
> modified counter-mode AES.
I now actually have most of the code
The program below gives somewhat random initialisers for the
three pools in the random(4) driver. It is sort of a compile
time equivalent of dumping /var/run/random-seed in.
If /dev/urandom is present on the development machine
(as it should be in nearly all cases), data from it is used.
If not, t
I have been thinking about how random(4) might be redesigned and I now
have enough thoughts to put them on electrons and send them out. This
is all first-cut stuff, though I have thought about it some. It needs
comment, criticism and revision.
A few things I think we absolutely want to keep. At le
I'm working on a demon that collects timer randomness, distills it
some, and pushes the results into /dev/random.
My code produces the random material in 32-bit chunks. The current
version sends it to /dev/random 32 bits at a time, doing a write() and
an entropy-update ioctl() for each chunk. Obvi
On Thu, Sep 8, 2011 at 9:11 PM, Steve Grubb wrote:
> The system being low on entropy is another problem that should be addressed.
> For our
> purposes, we cannot say take it from TPM or RDRND or any plugin board. We
> have to have
> the mathematical analysis that goes with it, we need to know w
Jarod Wilson wrote:
> Ted Ts'o wrote:
>> Yeah, but there are userspace programs that depend on urandom not
>> blocking... so your proposed change would break them.
>> ...
> But only if you've set the sysctl to a non-zero value, ...
>
> But again, I want to stress that out of the box, there's ab
On Fri, Sep 2, 2011 at 10:37 PM, Jarod Wilson wrote:
> Certain security-related certifications and their respective review
> bodies have said that they find use of /dev/urandom for certain
> functions, such as setting up ssh connections, is acceptable, but if and
> only if /dev/urandom can block
On Thu, Sep 1, 2011 at 10:24 PM, Adam Tisovsky wrote:
> I’m doing some benchmarks of IPsec performance on Cisco router and I
> have experienced the situation described below. My question is whether
> anybody has performed similar tests on Linux (StrongSWAN, OpenSWAN,…)
> or any other security gat
On Mon, Aug 8, 2011 at 1:48 PM, Locktyukhin, Maxim
wrote:
> 20 (and more) cycles per byte shown below are not reasonable numbers for SHA-1
> - ~6 c/b (as can be seen in some of the results for Core2) is the expected
> results ...
Ten years ago, on Pentium II, one benchmark showed 13 cycles/byte
87 matches
Mail list logo
