This reminds me of an issue that (at one time, I'm not current on it) was
an issue with OpenSSL in virtual environments.
When you restore a virtual machine snapshot, OpenSSL would maintain the
entropy state from the snapshot. It apparently did not refresh it's
userspace pool very often, so multipl
On second thought, there is this particular case, wherein you would need
internally generated entropy:
1. You have a cloud server which has been compromised.
2. You issue a remote reboot, with the firmware instructed to boot from the
network.
3. In order to obtain the new OS image, the cloud ser
"I see a few problems with that. First 128 bits of entropy is a lot to ask
from a human and you'll end up with a string of however many 'a' character
you asked for."
You're right, but there's nothing that can be done to help someone who
enters "cat" as his password, either.
"I personally don't th
> I still think it's important that TRNGs be practical in real usage contexts.
> As mundane as it sounds, perhaps the safest practice is just to ask the user
> to enter 50 random digits when they install the OS (or shake the mouse or
> whatever). At some point (100 digits?), even an uncreative pers
Things do indeed seem to run down and fall apart, although it's possible to
encounter local maxima in the entropy of discrete systems which are not
global maxima (depending on how you define entropy). So it ain't totally
straight downhill. I guess that bodes well for the health supplement
industry.
I was actually surprised how uncompressible the timedelta stream
does not make any sense. the result of a complex recursive chaotic
calculation always appears uncompressible, unless you know the proper
underlying model. trying to compress it only puts an upper limit on
entropy, but never an est
On Fri, May 29, 2015 at 12:25 AM, Russell Leidich wrote:
> I'm the first to admit that I don't understand where the entropy is coming
> from.
knowing where the entropy is coming from and knowing the amount of
entropy is the same thing. it is because we don't have a way to
measure entropy. we can
I'm the first to admit that I don't understand where the entropy is coming
from. I was actually surprised how uncompressible the timedelta stream
actually is (as shown by timedeltasave and timedeltaprofile, on my rather
idle system). Perhaps more of it is from DMAs competing for main memory
access,
On Thu, May 28, 2015 at 6:59 AM, James A. Donald wrote:
> The system can be thought of as pseudorandom number generator that is
> continually seeded by a small amount of true randomness.
beware about seeding. as the wisdom goes, once you seeded your prng
with at least 128 bit entropy, you don't
On 2015-05-27 22:14, Krisztián Pintér wrote:
On Wed, May 27, 2015 at 3:12 AM, Russell Leidich wrote:
"if your proposed method comes with a complex extractor, it is bullshit"
OK point well taken. I should offer a raw mode.
no, you actually shouldn't. you should offer raw mode only. maybe some
That's an amazing attack which is even more impressive for being from 2005.
It does make sense that in an algo as light as AES, cache misses would
stick out like a sore thumb.
While I don't think this sort of attack works in fill mode (because the
timing granularity is huge), it could theoreticall
>My contention is that those processes are too hard to model in any
>realistic OS context. But maybe there's a really simple but useful system
>in which that's not the case.
It seems unbelievable to do a key recovery attack based by measureing
cache timing of AES, yet lo and behold we
I generally agree with your proposed methods of sponging out entropy.
The result of your emulator experiment is a foregone conclusion, unless
there's a bug somewhere:
1. If the emulator is counting some fake notion of clocks-per-instruction,
then Enranda in fill mode will fail to fill because we'
On May 27, 2015, at 5:14 AM, Krisztián Pintér wrote:
> by definition, entropy is anything the attacker does not know.
No, entropy is anything about your own physical situation that *you* don’t
know. That may or may not be something your attacker also doesn’t know. This
is the fundamental re
On Wed, May 27, 2015 at 3:18 PM, Russell Leidich wrote:
> I realize that anyone can whiten a long stream of weak entropy into a short
> stream of strong entropy. But I disagree that doing so properly, in this
> case, is trivial.
here is a general solution:
1, initialize a cryptographic sponge
2,
I realize that anyone can whiten a long stream of weak entropy into a short
stream of strong entropy. But I disagree that doing so properly, in this
case, is trivial. The way Enranda does it, you need to predict events
separated by tens of thousands of aperiodic timedelta sequences in order to
crea
On Wed, May 27, 2015 at 3:12 AM, Russell Leidich wrote:
> "if your proposed method comes with a complex extractor, it is bullshit"
>
> OK point well taken. I should offer a raw mode.
no, you actually shouldn't. you should offer raw mode only. maybe some
clever compression just to reduce the amoun
On 27/05/2015 04:28 am, Steve Weis wrote:
On Tue, May 26, 2015 at 7:27 PM, Russell Leidich mailto:pke...@gmail.com>> wrote:
Unfortunately, that page doesn't provide insights as to why that
piece of advice was issued.
On Wed, May 27, 2015 at 2:11 AM, Naveen Nathan mailto:nav...@lastn
On Wed, May 27, 2015 at 2:54 AM, Stuart Christmas
wrote:
> the answers to all your questions are in the blog - you just have to have
> the patience to read it.
no, the right place for this information is on the front page, with
super big sans-serif typeface. trust me, i spent some 5 minutes to
fi
Hi Steve,
Yeah, the TSD bit probably should have been set from day one. But it
wasn't, so userspace TRNGs are possible. Nonetheless, TSD does not
constitute a threat to randomness: it would just result in a CPU privilege
violation, followed by shutdown of Enranda. Not good, but certainly not
ambig
On Tue, May 26, 2015 at 7:27 PM, Russell Leidich wrote:
> Unfortunately, that page doesn't provide insights as to why that piece of
> advice was issued.
>
> On Wed, May 27, 2015 at 2:11 AM, Naveen Nathan
> wrote:
>
>> Avoid: userspace random number generators, havaged, prngd, egd,
>> /dev/random
Hi Naveen,
Unfortunately, that page doesn't provide insights as to why that piece of
advice was issued.
And ultimately, even hardware TRNGs need to shuttle their outputs across
many radiating cables in order to arrive at their destination in memory,
even if we assume trusted components. So apart
Avoid: userspace random number generators, havaged, prngd, egd, /dev/random.
Source: https://gist.github.com/tqbf/be58d2d39690c3b366ad
Now that's advice I can get behind.
On Tue, May 26, 2015 at 03:49:14PM -0700, coderman wrote:
> On 5/26/15, Krisztián Pintér wrote:
> > i call bullshit on this
"you are patient and friendly in response to me, a jerk flinging opinions!"
No worries, coderman. No one ever got into cryptography to bask in the
charm of one's peers. Besides, I'm willing to put up with a lot in order to
get constructive criticism. (So relax, Stuart Christmas...) So yeah, when
y
Hi Krisztian,
"if your proposed method comes with a complex extractor, it is bullshit"
OK point well taken. I should offer a raw mode. ("make timedeltasave" then
run "temp/timedeltasave" for the help text) already does this, but I should
build it into Enranda directly. Obviously, the timedelta st
Krisztián Pintér -
the answers to all your questions are in the blog - you just have to have
the patience to read it.
There are calculations and statistical analysis, mostly in the form of the
Dyspoissonism metric. And Enranda doesn't just sit there looking at IRQ's
and timestamps like the RNG's w
On 5/26/15, Krisztián Pintér wrote:
> i call bullshit on this one, just as i called bullshit on havege...
dakarand is the other to add to this set, as well as the high
resolution timer based userspace rng daemon mods...
best regards,
___
cryptography m
i call bullshit on this one, just as i called bullshit on havege. a
proper hwrng always outputs the raw, unfiltered random bits. and an
estimate of the the entropy content. whitening is easy, and can be
done various ways, it is not interesting. many times we don't even
want whitening, because we a
On 5/26/15, Russell Leidich wrote:
> ...
> I would welcome your longer reply,
you are patient and friendly in response to me,
a jerk flinging opinions!
i will send a longer response about my specific concerns for these
types of entropy gathering when time permits - thank you for courtesy
un-des
Hi coderman,
I would welcome your longer reply, which would surely interest others here,
as well. For starters, how do you envision this BTC boundary attack
occurring? And yes, it's totally legit to attack Enranda by executing a
process on the same CPU, for example, in another terminal window on a
On 5/26/15, coderman wrote:
> ...
> others may provide constructive criticism, as you seem sincere in your
> desire for building useful entropy collection. but this solution is
> worse than nothing, as it provides absurd claims of false security.
speaking of,
'''
'If you can demonstrate that En
On 5/26/2015 2:01 PM, coderman wrote:
On 5/25/15, Russell Leidich wrote:
...
Enranda is a cryptographically secure (in the postquantum sense) true
random number generator requiring nothing but a timer (ideally, the CPU
timestamp counter). It produces roughly 4 megabytes of noise per second,
whi
On 5/26/2015 1:46 PM, coderman wrote:
On 5/26/15, Kevin wrote:
Are we talking about entropy taken from hard drive turbulence, the
keyboard or mouse, heat decay, or what?
"... requiring nothing but a timer (ideally, the CPU timestamp counter)"
for comparison, i run XSTORE on 1Ghz Padlock enabl
On 5/25/15, Russell Leidich wrote:
> ...
> Enranda is a cryptographically secure (in the postquantum sense) true
> random number generator requiring nothing but a timer (ideally, the CPU
> timestamp counter). It produces roughly 4 megabytes of noise per second,
> which puts it in the same bandwidt
On 5/26/15, Kevin wrote:
> Are we talking about entropy taken from hard drive turbulence, the
> keyboard or mouse, heat decay, or what?
"... requiring nothing but a timer (ideally, the CPU timestamp counter)"
for comparison, i run XSTORE on 1Ghz Padlock enabled processor at >100Mbps.
better tha
On 5/25/2015 11:01 PM, Russell Leidich wrote:
As annouced here in the original Jytter blog:
http://jytter.blogspot.com
It has been a long 3 years since Jytter was released. Enranda is now
available for download, analysis, and criticism. It's open source with
awesome licensing terms, courtesy
As annouced here in the original Jytter blog:
http://jytter.blogspot.com
It has been a long 3 years since Jytter was released. Enranda is now
available for download, analysis, and criticism. It's open source with
awesome licensing terms, courtesy of Tigerspike:
http://tigerspike.com
Enranda is
37 matches
Mail list logo
