linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeffrey Walton <noloader@gmail.com>
To: linux-crypto@vger.kernel.org
Subject: (unknown)
Subject: 
Date: Wed, 1 Jun 2016 00:21:02 -0400	[thread overview]
Message-ID: <CAH8yC8kZuhG92QJJgg27f0S1SrFp2RbMb19GuocfMYc++x9t3g@mail.gmail.com> (raw)

Please forgive my ignorance here...

I have test system with a VIA C7-M processor and PM-400 chipset. This
is one of those Thin Client/Internet of Things processor and chipsets
I test security libraries on (like OpenSSL, Cryptlib and Crypto++).

The processor includes the Padlock extensions. Padlock is similar to
Intel's RDRAND, RDSEED and AES-NI, and it predates Intel's
instructions by about a decade.

The Padlock Security Engine can produce a stream of random numbers at
megabits per socond, so I've been kind of surprised it has been
suffering entropy depletion. Here's what the audit trail looks like:

    Testing operating system provided blocking random number generator...
    FAILED:  it took 74 seconds to generate 5 bytes
    passed:  5 generated bytes compressed to 7 bytes by DEFLATE

Above, the blocking RNG is drained. Then, 16 bytes are requested. It
appears to take over one minute to gather five bytes when effectively
an endless stream is available.

My question is, is this system expected to suffer entropy depletion
out of the box? Or are users expected to do something special so the
system does not fail?

Thanks in advance.

Jeff

             reply	other threads:[~2016-06-01  4:21 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01  4:21 Jeffrey Walton [this message]
2016-06-01  4:59 ` (none) Herbert Xu
2016-06-01  5:53   ` (none) Stephan Mueller
2016-06-01  6:19     ` (none) Herbert Xu
2016-06-01  6:59       ` (none) Jeffrey Walton
2016-06-01  7:05         ` (none) Stephan Mueller
2016-06-01  7:05         ` (none) Herbert Xu
  -- strict thread matches above, loose matches on Subject: below --
2017-10-20  8:42 (unknown), membership
2017-10-17  0:33 (unknown), membership
2017-10-06  8:31 (unknown), smallgroups
2017-10-04 15:33 (unknown), membership
2017-09-22  3:39 (unknown), service
2017-09-02  0:58 (unknown), smallgroups
2017-09-01 11:40 (unknown), witt.kohl
2017-08-31  4:52 (unknown), archerrp
2017-08-25  0:32 (unknown), agiva
2017-08-11  6:14 (unknown), администратор 
2017-08-09 10:20 (unknown), системы администратор
2017-08-02  3:45 (unknown), системы администратор
2017-07-13  4:49 (unknown), delaware.orders
2017-07-10 21:53 (unknown), agiva
2017-07-10  3:45 (unknown), системы администратор
2017-07-09 13:02 (unknown), smallgroups
2017-07-05  6:55 (unknown), agiva
2017-06-28  3:56 (unknown), системы администратор
2017-06-25  5:14 (unknown), archerrp
2017-06-24 15:03 (unknown), archerrp
2017-06-23 12:26 (unknown), archerrp
2017-06-18 13:58 (unknown), membership
2017-06-13 21:38 (unknown), douille.l
2017-06-11  0:20 (unknown), service
2017-06-10  5:29 (unknown), agiva
2017-06-08 14:09 (unknown), service
2017-06-04 19:55 (unknown), archerrp
2017-06-01  1:55 (unknown), cdevries
2017-05-23 16:24 (unknown), agiva
2017-05-23  8:42 (unknown), delaware.orders
2017-05-21  8:55 (unknown), agiva
2017-05-19  4:32 (unknown), archerrp
2017-05-18 14:13 (unknown), agiva
2017-04-28  8:36 (unknown), администратор
2017-04-21 17:06 (unknown), Mr.Jerry Smith
2017-04-21  9:25 (unknown), delaware.orders
2017-04-15 13:53 (unknown), smallgroups
2017-04-10  5:46 (unknown), archerrp
2017-04-06 13:43 (unknown), agiva
2017-01-19  4:56 (unknown), archerrp
2017-01-13 11:28 (unknown), service
2017-01-03  6:57 (unknown), системы администратор
2017-01-03  6:48 (unknown), системы администратор
2017-01-03  6:48 (unknown), системы администратор
2016-12-18 10:35 (unknown), linux-crypto
2016-12-16 10:46 (unknown), системы администратор
2016-12-14 18:22 (unknown), witt.kohl
2016-08-30 15:53 (unknown), Iaroslav Gridin
2016-05-15  3:15 (unknown), membership
2016-04-08  2:06 (unknown) contact
2015-10-23 12:10 (unknown), LABBE Corentin
2015-09-23 10:48 (unknown), jerryfunds247777
2015-08-30  1:57 (unknown), jerryfunds3
2015-08-29 18:29 (unknown), jerryfunds20
2015-07-01 11:53 (unknown), Sasnett_Karen
2012-05-25 13:45 (unknown), robothroli company
2012-05-05 18:59 (unknown), Mrs Sabah Halif
2012-02-15 17:47 (unknown), Ann Adams
2011-05-21 12:54 (unknown), western101@algish.com
2010-09-06 13:34 (unknown), Jan Chadima
2010-09-05  0:36 (unknown), Tobias Karnat
2009-07-27 16:23 (unknown) vivianofferplc013

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH8yC8kZuhG92QJJgg27f0S1SrFp2RbMb19GuocfMYc++x9t3g@mail.gmail.com \
    --to=noloader@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).