On Mon, 2 Aug 2010, Nicolas Williams wrote:
If that was a major issue, then SSL would have been much more successful
then it has been.
How should we measure success?
The default mode for any internet communication is encrypted
By that measure TLS has been so much more successful than
On 2 aug 2010, at 16.51, Jeffrey Schiller wrote:
Does the root KSK exist in a form that doesn't require the HSM to
re-join, or more to the point if the manufacturer of the HSM fails, is
it possible to re-join the key and load it into a different vendor's
HSM?
With the assistance of the
On 2 aug 2010, at 08.30, Peter Gutmann wrote:
For the case of DNSSEC, what would happen if the key was lost? There'd be a
bit of turmoil as a new key appeared and maybe some egg-on-face at ICANN, but
it's not like commercial PKI with certs with 40-year lifetimes hardcoded into
every
On Mon, 2 Aug 2010 16:20:01 -0500 Nicolas Williams
nicolas.willi...@oracle.com wrote:
But users have to help you establish the context. Have you ever
been prompted about invalid certs when navigating to pages where
you couldn't have cared less about the server's ID? On the web,
when does
On Mon, 2 Aug 2010 16:19:38 -0400 (EDT) Paul Wouters
p...@xelerance.com wrote:
[Speaking here about DNSSEC...]
Yes, but in some the API is pretty much done. If you trust your
(local) resolver, the one bit is the only thing you need to check.
You let the resolver do most of the bootstrap
At 10:38 PM +0300 8/2/10, Yaron Sheffer wrote:
the interesting thread on seeding and reseeding /dev/random did not mention
that many of the most problematic systems in this respect are virtual
machines. Such machines (when used for cloud computing) are not only
servers, so have few sources of
On Mon, 02 Aug 2010, Yaron Sheffer wrote:
the interesting thread on seeding and reseeding /dev/random did not
mention that many of the most problematic systems in this respect
are virtual machines. Such machines (when used for cloud
Any decent hypervisor can supply entropy to the VMs. For
There is no guarantee, once an eavesdropping system is
implemented, that it will be used only for legitimate purposes -- see,
for example, the scandal in which Greek government ministers were
listened to using the lawful intercept features of cellphone
equipment.
And, by the way, what ever
On Mon, 2 Aug 2010, Yaron Sheffer wrote:
In addition to the mitigations that were discussed on the list, such machines
could benefit from seeding /dev/random (or periodically reseeding it) from
the *host machine's* RNG. This is one thing that's guaranteed to be different
between VM instances.
Hi,
we are using haveged in our VMs to feed the random pool and
it seems to work good (means: statistical verification of
the output looks good, nearly 0 entropy overestimation, but
we never correlated output from cloned VMs).
I assume feeding the VMs from the host system can be problematic
On Aug 2, 2010, at 1:25 PM, Nicolas Williams wrote:
On Mon, Aug 02, 2010 at 12:32:23PM -0400, Perry E. Metzger wrote:
Looking forward, the there should be one mode, and it should be
secure philosophy would claim that there should be no insecure
mode for a protocol. Of course, virtually all
I recently came across an example of a file-hiding rootkit for Windows that's
used for good instead of evil: It's a minifilter that hides (or at least
blocks, the files are still visible) access to executables on removable media,
with user-configurable options to block autorun.inf and/or all
Peter Gutmann wrote:
That's a good start, but it gets a bit more complicated than that in practice
because you've got multiple components, and a basic red light/green light
system doesn't really provide enough feedback on what's going on. What you'd
need in practice is (at least) some sort of
On Mon, Aug 02, 2010 at 03:46:24PM -0500, Nicolas Williams wrote:
The default mode for any internet communication is encrypted
That's... extreme. There are many things that will not be encrypted,
Extreme? I don't see why my ISP should be able to inspect and monetize
my data stream.
On Tue, 3 Aug 2010 17:49:00 +0200 Eugen Leitl eu...@leitl.org wrote:
Encryption is cheap enough (especially if you cache keys from
previous sessions). Why not encrypt everything?
I'm not sure it is actually cheap enough in all cases. Imagine the
state explosion problem that DNS root servers
On Mon, 2 Aug 2010 20:17:42 -0300 Henrique de Moraes Holschuh
h...@debian.org wrote:
Desktops with live-CDs and half-assed embedded boxes that lack a
TRNG are the real problem.
I'm not sure what to do about the live CD problem, but in a previous
iteration of this discussion a couple of years
We have been discussing the importance of a unique random-seed
file each system. This is important even forsystems that boot
from read-only media such as CD.
To make this somewhat more practical, I have written a script
to remix a .iso image so as to add one or more last-minute files.
The
On Mon, 02 Aug 2010, Paul Wouters wrote:
On Mon, 2 Aug 2010, Yaron Sheffer wrote:
In addition to the mitigations that were discussed on the list,
such machines could benefit from seeding /dev/random (or
periodically reseeding it) from the *host machine's* RNG. This is
one thing that's
The discussion spurred by Peter Gutmann's original mail on
astonishingly widely authoritative certs has gone on for quite a
while, and much of what is now being said is repetitive. I'll be
using a pretty heavy hand on moderating the messages for the moment,
unless people come up with particularly
19 matches
Mail list logo
