On Sep 10, 2013, at 3:56 PM, Bill Stewart bill.stew...@pobox.com wrote:
One point which has been mentioned, but perhaps not emphasised enough - if
NSA have a secret backdoor into the main NIST ECC curves, then even if the
fact of the backdoor was exposed - the method is pretty well known -
(curse you anti-gmail-top-posting zealots...)
On Wed, Sep 11, 2013 at 3:47 PM, Dave Horsfall d...@horsfall.org wrote:
Another whacky idea...
Given that there is One True Source of randomness to wit radioactive
emission, has anyone considered playing with old smoke detectors?
Yep. For fun I
On 9/11/2013 6:47 PM, Dave Horsfall wrote:
Given that there is One True Source of randomness to wit radioactive
emission, has anyone considered playing with old smoke detectors?
I did that a decade ago, to wit:
http://etoan.com/random-number-generation/index.html
Cheers,
Dan
http://people.umass.edu/gbecker/BeckerChes13.pdf
Stealthy Dopant-Level Hardware Trojans ?
Georg T. Becker1
, Francesco Regazzoni2
, Christof Paar1,3 , and Wayne P. Burleson1
1University of Massachusetts Amherst, USA
2TU Delft, The Netherlands and ALaRI - University of Lugano, Switzerland
On Thu, Sep 12, 2013 at 11:00:47AM -0400, Perry E. Metzger wrote:
In addition to getting CPU makers to always include such things,
however, a second vital problem is how to gain trust that such RNGs
are good -- both that a particular unit isn't subject to a hardware
defect and that the
On Thu, Sep 12, 2013 at 12:04 PM, Nico Williams n...@cryptonector.com wrote:
Note: you don't just want BTNS, you also want RFC5660 -- IPsec
channels. You also want to define a channel binding for such channels
(this is trivial).
I am not convinced. It's supposed to be *better than nothing*.
On 09/12/2013 10:38 PM, Thor Lancelot Simon wrote:
The audio subsystem actually posed *two* obvious opportunities:
amplifier noise from channels with high final stage gain but connected
by a mixer to muted inputs, and clock skew between system timers and
audio sample clocks. The former
[Perry - this is likely getting too far off-topic, but I've included the list
just in case you feel otherwise. -- J]
On Sep 12, 2013, at 12:53 AM, Andrew W. Donoho a...@ddg.com wrote:
On Sep 11, 2013, at 12:13 , Jerry Leichter leich...@lrw.com wrote:
On Sep 11, 2013, at 9:16 AM, Andrew
On Mon, Sep 09, 2013 at 10:25:03AM +0200, Eugen Leitl wrote:
Just got word from an Openswan developer:
To my knowledge, we never finished implementing the BTNS mode.
It wouldn't be hard to do --- it's mostly just conditionally commenting out
code.
There's obviously a large potential
On Wed, Sep 11, 2013 at 06:51:16PM -0400, Perry E. Metzger wrote:
It occurs to me that specifying IVs for CBC mode in protocols
like IPsec, TLS, etc. be generated by using a block cipher in counter
mode and that the IVs be implicit rather than transmitted kills two
birds with one stone.
The
On 09/11/2013 07:18 PM, Perry E. Metzger wrote:
the world's routers, servers, etc. do not have good sources,
especially at first boot time, and for customer NAT boxes and the like
the price points are vicious.
I agree that things like consumer NAT boxes have a tricky problem, and
anything
On 09/12/2013 10:41 AM, Kent Borg wrote:
routers and servers are not as bad off as people say.
Not that more sources is bad. A new trustworthy HW entropy source would
be good. Even a suspect rdrand is worth XORing in (as Linux does on the
machine I am using right now).
But if you thirst
On Wed, Sep 11, 2013 at 04:03:44PM -0700, Nemo wrote:
Phillip Hallam-Baker hal...@gmail.com writes:
I have attempted to produce a summary of the discussion so far for use
as a requirements document for the PRISM-PROOF email scheme. This is
now available as an Internet draft.
Executive summary:
The soundcard on one of my machines runs at 192000 Hz. My beat-up
old laptop runs at 96000. An antique server runs at only 48000.
There are two channels and several bits of entropy per sample.
That's /at least/ a hundred thousand bits per second of real
industrial-strength
On Thu, Sep 12, 2013 at 08:47:16AM +1000, Dave Horsfall wrote:
Another whacky idea...
Given that there is One True Source of randomness to wit radioactive
What makes you think that e.g. breakdown oin a reverse biased
Zener diode is any less true random? Or thermal noise in a
crappy CMOS
On Thu, Sep 12, 2013 at 09:33:34AM -0700, Tony Arcieri wrote:
What's really bothered me about the phrase perfect forward secrecy is
it's being applied to public key algorithms we know will be broken as soon
as a large quantum computer has been built (in e.g. a decade or two).
I do not think
On Thu, 12 Sep 2013, Nico Williams wrote:
Note: you don't just want BTNS, you also want RFC5660 -- IPsec
channels. You also want to define a channel binding for such channels
(this is trivial).
To summarize: IPsec protects discrete *packets*, not discrete packet
*flows*. This means that
[* Until Linux kernel 3.6 the person maintaining urandom was busily turning off interrupts as a source of entropy, I think because he didn't know how much entropy he was getting so better not to get it at all (huh?). In 3.6 this was changed to use all interrupts as entropy sources, which is
On 09/13/2013 11:59 AM, Marcus Leech wrote:
Any physical-world sensor driver, where the sensor inherently has a
bit of noise, I think has a moral obligation to contribute bits to
the kernel entopy pool.
Within limits. Mixing the entropy pool on Linux takes work and battery
power.
Looking
On Fri, 13 Sep 2013 11:49:24 +0200 Eugen Leitl eu...@leitl.org
wrote:
http://people.umass.edu/gbecker/BeckerChes13.pdf
Stealthy Dopant-Level Hardware Trojans[...]
This is pretty clearly a big deal. The fact that you can skew HRNGs
just by fiddling with dopant levels is something I would
On Wed, Sep 11, 2013 at 07:32:04PM +0200, Guido Witmond wrote:
With a FOAF routing scheme with just 3 degrees of separation there
are not that many strangers left.
How do you meet people outside your circle of friends?
You don't. The message is routed through the social network, until
it
On Fri, 13 Sep 2013 08:08:38 +0200 Eugen Leitl eu...@leitl.org
wrote:
Why e.g. SWIFT is not running on one time pads is beyond me.
I strongly suspect that delivering them securely to the vast number
of endpoints involved and then securing the endpoints as well would
radically limit the
On Fri, 13 Sep 2013 15:46:58 -0500 Nico Williams
n...@cryptonector.com wrote:
On Fri, Sep 13, 2013 at 03:17:35PM -0400, Perry E. Metzger wrote:
On Thu, 12 Sep 2013 14:53:28 -0500 Nico Williams
n...@cryptonector.com wrote:
Traffic analysis can't really be defeated, not in detail.
Switching from AES to one-time pads to solve your practical cryptanalysis
problems is silly. It replaces a tractable algorithm selection problem with a
godawful key management problem, when key management is almost certainly the
practical weakness in any broken system designed by non-idiots.
2013/9/10 james hughes hugh...@mac.com
[...]
Lastly, going a partial step seems strange also. Why do we what to put
ourselves through this again so soon? The French government suggests 2048
now (for both RSA and DHE), and will only last 6 years. From
On Fri, 13 Sep 2013 16:55:05 -0400 John Kelsey crypto@gmail.com
wrote:
Everyone,
The more I think about it, the more important it seems that any
anonymous email like communications system *not* include people who
don't want to be part of it, and have lots of defenses to prevent
its
On Thu, Sep 12, 2013 at 08:28:56PM -0400, Paul Wouters wrote:
Stop making crypto harder!
I think you're arguing that active attacks are not a concern. That's
probably right today w.r.t. PRISMs. And definitely wrong as to cafe
shop wifi.
The threat model is the key. If you don't care about
27 matches
Mail list logo
