-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am reminded of an article my dear old friend, Martin Minow, did in
Cryptologia ages ago. He wrote the article I think for the April 1984 issue. It
might not have been 1984, but it was definitely April.
In it, he described a cryptosystem in which y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 19, 2012, at 12:09 AM, Jon Callas wrote:
> * PGP Signed: 06/19/2012 at 12:09:46 AM
>
> I am reminded of an article my dear old friend, Martin Minow, did in
> Cryptologia ages ago. He wrote the article I think for the April 1984 issue.
> It
On Jun 18, 2012, at 4:21 PM, Jon Callas wrote:
Reviewers don't want a review published that shows they gave a pass on a crap
system. Producing a crap product hurts business more than any thing in the
world. Reviews are products. If a professional organization gives a pass on
something that tur
And, to get back on topic after having gone dangerously off topic:
The market for cryptography is the market for silver bullets: Those
actually paying money cannot tell the difference between real experts
and salesmen, thus the incentive to actually be any good at this is not
high.
On 06/19/2012 01:36 AM, Jon Callas wrote:
On Jun 18, 2012, at 4:12 PM, Marsh Ray wrote:
150 clocks (Intel's figure) implies 18.75 clocks per byte.
That's not bad at all.
Right, 500 MB/s of random numbers out to be enough for anybody.
My main point in running the perf numbers was to figure
On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray wrote:
>...
> Right, 500 MB/s of random numbers out to be enough for anybody.
these rates often are not useful. even busy secure web or VPN servers
use orders of magnitude less.
initialization of full disk crypto across an SSD RAID could consume
it, bu
coderman writes:
>On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray wrote:
>>...
>> Right, 500 MB/s of random numbers out to be enough for anybody.
>
>these rates often are not useful. even busy secure web or VPN servers use
>orders of magnitude less.
>
>initialization of full disk crypto across an SSD
On Tue, Jun 19, 2012 at 8:09 AM, Jon Callas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I am reminded of an article my dear old friend, Martin Minow, did in
> Cryptologia ages ago. He wrote the article I think for the April 1984 issue.
> It might not have been 1984, but it was d
What I think people react on is that it's really pointless to use decimals
and having to keep track of when they repeat. A simple RNG with normal
numbers could be used instead, and probably *should* be used unless your
crypto really *needs* numbers consisting of primes divided by primes.
So essent
I think your problems are these:
You don't understand what makes XOR (one time pad crypto) uncrackable (and
*that* is the term you want, not "undecryptable).
You can't explain the advantage of your system well.
It would be vulnerable to timing attacks if implemented (the time it takes
reveals da
Aloha!
On 2012-06-19 11:30 , coderman wrote:
> On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray wrote:
>> So something is causing AES-NI to take 300 clocks/block to run this DRBG.
>> Again, more than 3x slower than the benchmarks I see for the hardware
>> primitive. My interpretation is that either Rd
The digit sequence
0.1234567891011121314151617181920212223...
(or its equivalent in binary, hex, or your other favorite base)
never repeats, but provides no security whatsoever. One-time pads
need nonrepeating sequences *which the adversary can't predict*.
--
-- "Jonathan Thornburg [remove -an
Yes, it can be compressed to zero bits, and the decompression process will
generate two alternative outputs.
On Jun 19, 2012, at 8:06 AM, cryptography-requ...@randombit.net wrote:
> From: Ben Laurie
> To: Jon Callas
> Cc: Crypto List
> Subject: Re: [cryptography] non-decryptable encryption
>>
On Mon, Jun 18, 2012 at 09:58:59PM -0700, coderman wrote:
>
> this is very useful to have in some configurations (not just testing).
> for example: a user space entropy daemon consuming raw, biased,
> un-whitened, full throughput bits of lower entropy density which is
> run through sanity checks,
Hi!
The interesting discussion induced me to look again to the actual report
[1]. When I initially did, I came up with the impression that the RNG
design is sound to the extent that a) any system based on sampling an
unpredictable physical phenomenon has some intrinsic limitations, and b)
you
> Aloha!
>
> On 2012-06-19 11:30 , coderman wrote:
>> On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray
>> wrote:
>>> So something is causing AES-NI to take 300 clocks/block to run this
>>> DRBG.
>>> Again, more than 3x slower than the benchmarks I see for the hardware
>>> primitive. My interpretation i
For people interested in the future of secret-key cryptography, the list
of talks for next month's ECRYPT DIAC workshop has now been posted:
http://hyperelliptic.org/DIAC
Registration is still open today:
http://hyperelliptic.org/DIAC/registration.html
Here's the list of invited speakers
On Tue, Jun 19, 2012 at 9:02 AM, wrote:
>...
> It is not using AES-NI. It is a self contained unit on chip with a built
> in HW AES encrypt block cipher.
thanks for the clarification; is this documented somewhere? i am
curious if the die space consumed for two implementations of AES in
negligabl
On 06/19/2012 01:59 PM, coderman wrote:
thanks for the clarification; is this documented somewhere? i am
curious if the die space consumed for two implementations of AES in
negligable on these very large cores, or if there is another reason to
intentionally keep them separate.
It sounds to me l
On Tue, Jun 19, 2012 at 6:17 AM, Thor Lancelot Simon wrote:
> ...
> Sanity checks, entropy estimates, and other vetting *which the output
> of a DRBG keyed in a known way by your adversary will pass without
> a hint of trouble*.
absolutely; after it has gone through DRBG you have zero visibility
> i'll concede the point that you'd only want raw bits to validate CRI
> and Intel assurances, and they've done due diligence.
>
> this is something i like to verify myself; no fault with the Intel
> design or CRI analysis implied.
If you assume that every manufactured device will meet the standa
> > I would really love to hear some examples from the security world.
>
> The canonical example I was thinking of was Arthur Anderson, which
> doesn't meet your definition, I'm sure.
I would not wait for such clarity; the bond rating agencies still
live while the sovereigns they rated are busi
On 06/19/2012 02:11 PM, coderman wrote:
the sanity checks, being on die, are limited. you can't run DIEHARD
against this in a useful manner because the DRBG obscures anything
useful.
I don't think there's anything useful diehard (specifically) is going to
tell you.
The raw entropy source ou
On 2012-06-19 4:51 AM, Matthew Green wrote:
> 1. Private evaluation report (budgeted to, say, 200 hours)
> probabilistically identifies N serious vulnerabilities. We
> all know that another 200 hours could turn up N more. In
> fact, the code may be riddled with errors. Original N
> vulnerabilities
absolutely true. i mentioned (in my article) that after explaining the masking.
--- jth...@astro.indiana.edu wrote:
From: Jonathan Thornburg
To: jam...@echeque.com, cryptography@randombit.net
Subject: Re: [cryptography] non-decryptable encryption
Date: Tue, 19 Jun 2012 08:30:59 -0400 (EDT)
Th
On 2012-06-19 8:03 PM, Givonne Cirkin wrote:> i don't understand why is
it clear to some & they get it right away. why do others not see it? i
thought i was clear to use the sequence up until the first repeat.
This is just one time pad.
___
crypt
Anyone know any technical details about this? From the news reports I've
seen, it's not even clear to me what, exactly, was broken.
http://www.pcworld.com/businesscenter/article/257902/researchers_set_new_cryptanalysis_world_record_for_pairingbased_cryptography.html
> On 06/19/2012 02:11 PM, coderman wrote:
>>
>> the sanity checks, being on die, are limited. you can't run DIEHARD
>> against this in a useful manner because the DRBG obscures anything
>> useful.
>
> I don't think there's anything useful diehard (specifically) is going to
> tell you.
>
> The raw e
On Tue, Jun 19, 2012 at 1:54 PM, Marsh Ray wrote:
> ... Just a sanity check that the output is
> actually changing once in a while would go a long way towards
> eliminating the most common failure modes.
On Tue, Jun 19, 2012 at 6:58 PM, wrote:
> ... Actually having a perfect source is a problem
On Tue, Jun 19, 2012 at 07:35:03PM -0700, coderman wrote:
>
> is there any literature on the typical failure modes of TRNG/entropy
> sources in deployed systems?
>
> my understanding is that they tend to fail catastrophically, in a way
> easily detected by FIPS sanity checks. E.g. clearly broken.
On 2012-06-19 7:02 AM, Jack Lloyd wrote:
You're
not saying that CRI would hide things, you're just saying that
accepting payment sets the incentives all the wrong way and that all
companies would put out shoddy work so long as they got paid,
especially if giving a bad review would make the custom
On 2012-06-19 9:07 AM, d...@deadhat.com wrote:
It does tell you that if it is your chip and you don't let
someone else pull the lid off, scrape off the passivation and apply a pico
probe to it, it will certainly provide you with good random numbers
regardless of the FIPS mode.
I don't know that
On 20/06/12 13:25 PM, James A. Donald wrote:
On 2012-06-19 7:02 AM, Jack Lloyd wrote:
You're
not saying that CRI would hide things, you're just saying that
accepting payment sets the incentives all the wrong way and that all
companies would put out shoddy work so long as they got paid,
especiall
On 6/19/2012 7:35 PM, coderman wrote:
On Tue, Jun 19, 2012 at 1:54 PM, Marsh Ray wrote:
... Just a sanity check that the output is
actually changing once in a while would go a long way towards
eliminating the most common failure modes.
On Tue, Jun 19, 2012 at 6:58 PM, wrote:
... Actually ha
On 2012 Jun 19, at 20:25 , James A. Donald wrote:
> On 2012-06-19 7:02 AM, Jack Lloyd wrote:
>> You're
>> not saying that CRI would hide things, you're just saying that
>> accepting payment sets the incentives all the wrong way and that all
>> companies would put out shoddy work so long as they g
On Tue, Jun 19, 2012 at 2:30 AM, coderman wrote:
> ...
> as for stating that it should never "run dry", or fail to not return
> bits as long as the instruction is working...
i was incorrect; developers should expect this instruction to
infrequently encounter transitory failures requiring retry:
Aloha!
On 2012-06-20 05:32 , James A. Donald wrote:
> If intel told me how it worked, and provided low level access to raw
> unwhitened output, I could find pretty good evidence that the low level
> randomness generator was working as described, and perfect evidence that
> the whitener was working
On 2012-06-20 2:17 PM, David Johnston wrote:
If an entropy source in a closed system is producing an apparently non
repeating, unbiased sequence and its output is deterministic (or low
entropy) then there must be internal memory in the entropy source that
is enabling the non repeating behavior. T
38 matches
Mail list logo
