On 27/01/11 19:19, Steven Bellovin wrote:
>
> On Jan 27, 2011, at 8:37 45AM, Len Sassaman wrote:
>
>> On Wed, 26 Jan 2011, Thierry Moreau wrote:
>>
>>> 2) a host plus some H/W for true random source
>>
>> Speaking of hardware entropy sources, has anyone analyzed the Simtek
>> Electronics Entr
On Fri, Jan 28, 2011 at 12:25:29PM -0600, Marsh Ray wrote:
> Well, I was thinking about what the min-privilege such a device
> would need. Even though most folks will probably just end up running
> this code as root, in theory the driver needs to be able to only do
> a few things:
> * talk to the U
On 01/28/2011 05:43 AM, Daniel Silverstone wrote:
On Thu, Jan 27, 2011 at 12:03:26PM +, Marsh Ray wrote:
[Disclaimer: I work for Simtec and worked on the Entropy Key. We are honestly
interested in frank and open discourse about the device and in that spirit, my
comments follow.]
Cool
Fo
On Thu, Jan 27, 2011 at 12:03:26PM +, Marsh Ray wrote:
[Disclaimer: I work for Simtec and worked on the Entropy Key. We are honestly
interested in frank and open discourse about the device and in that spirit, my
comments follow.]
> For example, this key requires a daemon to operate. On *nix
On Jan 27, 2011, at 8:37 45AM, Len Sassaman wrote:
> On Wed, 26 Jan 2011, Thierry Moreau wrote:
>
>> 2) a host plus some H/W for true random source
>
> Speaking of hardware entropy sources, has anyone analyzed the Simtek
> Electronics Entropy Key (http://www.entropykey.co.uk/)? It's a USB dong
On 01/27/2011 07:37 AM, Len Sassaman wrote:
On Wed, 26 Jan 2011, Thierry Moreau wrote:
2) a host plus some H/W for true random source
Speaking of hardware entropy sources, has anyone analyzed the Simtek
Electronics Entropy Key (http://www.entropykey.co.uk/)? It's a USB
dongle, recommended to
On Wed, 26 Jan 2011, Thierry Moreau wrote:
2) a host plus some H/W for true random source
Speaking of hardware entropy sources, has anyone analyzed the Simtek
Electronics Entropy Key (http://www.entropykey.co.uk/)? It's a USB dongle,
recommended to me by several remailer operators. To quote
On 01/25/2011 06:30 AM, Sandy Harris wrote:
If an enemy gets root on your system, then your secure storage is no
longer secure.
I believe the technical term for this is "pwned".
By all means, if you have something like /dev/random
or another buffering scheme, store some state and throw it in
You should presume your CPRNG output is public (eg published on the web)
What we are talking about in the real world is C_P_RNGs and the C
cryptographic means its suitable for crypto uses, and pseudo means its a
tool for stretching some adequate supply of real entropy (eg 128-bits,
256-bits or w
Peter Gutmann wrote:
Oh, and just to throw a spanner in the works: I've never seen any standards
document or whatever that discusses what to do when you don't have enough
entropy available. There are all sorts of Rube-Goldberg entropy-estimation
methods, but what do you do when your entropy-
Peter Gutmann wrote:
Thierry Moreau writes:
As a derived engineering strategy, wouldn't it be better to design a system
where the long-term secrets are kept in a "secure" co-processor,
Yes, of course, but that's asking the wrong question, what you need to ask is:
As a product manufacturi
On Tue, Jan 25, 2011 at 5:59 PM, Adam Back wrote:
> I think for its flaws, its still significantly useful that a FIPS algorithm
> or crypto library certificate certifies that an implementation passes its
> test vectors, startup tests etc. It gives some reasonable assurance that
> the algorithm is
Thierry Moreau writes:
>As a derived engineering strategy, wouldn't it be better to design a system
>where the long-term secrets are kept in a "secure" co-processor,
Yes, of course, but that's asking the wrong question, what you need to ask is:
As a product manufacturing strategy, should we
Jack Lloyd writes:
>The problem with this approach is the people doing the certifying do not
>actually understand cryptography or security engineering in any meaningful way,
>so have no real ability to make such judgements.
I think they understand cryptography quite well, it's security engineer
On 2011-01-26 8:59 AM, Adam Back wrote:
I think for its flaws, its still significantly useful that a FIPS algorithm
or crypto library certificate certifies that an implementation passes its
test vectors, startup tests etc. It gives some reasonable assurance that
the algorithm is implemented accor
I think for its flaws, its still significantly useful that a FIPS algorithm
or crypto library certificate certifies that an implementation passes its
test vectors, startup tests etc. It gives some reasonable assurance that
the algorithm is implemented according to the spec, and typically some
tho
On 2011-01-26 12:10 AM, Jack Lloyd wrote:
The problem with this approach is the people doing the certifying do
not actually understand cryptography or security engineering in any
meaningful way, so have no real ability to make such judgements.
An attempt to provide certification by idiots is un
On 2011-01-25 11:46 PM, Peter Gutmann wrote:
Oh, and just to throw a spanner in the works: I've never seen any standards
document or whatever that discusses what to do when you don't have enough
entropy available. There are all sorts of Rube-Goldberg entropy-estimation
methods, but what do you d
Thanks Sandy, Peter and Jack for the feedback.
Just one clarification on a question I ask myself, see below.
Sandy Harris wrote:
Thierry Moreau wrote:
Bursts of cryptographic operations consuming random data will
force either a PRNG expander of randomness or true random data buffering,
both
On Wed, Jan 26, 2011 at 02:46:30AM +1300, Peter Gutmann wrote:
> this. The other problem is that their long-term goal is to create something
> certifiable, which means you need repeatability and determinism... for a
> process that's supposed to be inherently nondeterministic. A better approach
>
Thierry Moreau writes:
>So, here are a few highlights of my recent findings. I found that too many
>notions deserved a description of rationales, and hence a draft-in-progress
>document is just stalled.
The problem here is that the debate rapidly goes from engineering to
philosophy, and then you
Thierry Moreau wrote:
> Only NIST (with the help of NSA and participants in a circa 2004 symposium)
> advanced the true random source standardization effort, with the main
> outcome being NIST SP-800-90. Neither the financial industry (ANSI) nor the
> European digital signature got any noticeable
Dear cryptography enthusiasts!
Glad to see a mailing list still in operations for applied cryptography.
In my ever ensuing quest for proper implementation of applied
cryptographic techniques, I spent some time on the source of random
secrets in a security system. I also reviewed the "best prac
23 matches
Mail list logo
