On 10/10/2013 02:20 PM, Ray Dillinger wrote:
split the message stream
into channels when it gets to be more than, say, 2GB per day.
That's fine, in the case where the traffic is heavy.
We should also discuss the opposite case:
*) If the traffic is light, the servers should generate cover
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/25/2013 04:59 AM, Peter Gutmann wrote:
Something that can sign a new RSA-2048 sub-certificate is called a CA. For
a browser, it'll have to be a trusted CA. What I was asking you to explain
is
how the browsers are going to deal with
Previously I said we need to speak more carefully about these
things. Let me start by taking my own advice:
Alas on 09/14/2013 12:29 PM, I wrote:
a) In the linux random device, /any/ user can mix stuff into the
driver's pool. This is a non-privileged operation. The idea is that
it can't
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 09/05/2013 05:11 PM, Perry E. Metzger wrote:
A hardware generator can have
horrible flaws that are hard to detect without a lot of data from many
devices.
Can you be more specific? What flaws?
On 09/08/2013 08:42 PM, James A. Donald wrote:
It is hard, perhaps impossible, to have test
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/05/2013 06:48 PM, Richard Clayton wrote:
so you'd probably fail to observe any background activity that tested
whether this information was plausible or not and then some chance
event would occur that caused someone from Law Enforcement
I don't have any hard information or even any speculation about
BULLRUN, but I have an observation and a question:
Traditionally it has been very hard to exploit a break without
giving away the fact that you've broken in. So there are two
fairly impressive parts to the recent reports: (a)
On 06/28/2013 04:00 PM, John Gilmore wrote:
Let's try some speculation about what this phrase,
fabricating digital keys, might mean.
Here's one hypothesis to consider.
a) The so-called digital key was not any sort of decryption key.
b) The files were available on the NSA machines in the
On 10/08/2010 04:27 PM, Perry E. Metzger wrote:
I have a client with the following problem. They would like to
encrypt all of their Windows workstation drives, but if they do that,
the machines require manual intervention to enter a key on every
reboot. Why is this a problem? Because
On 08/02/2010 10:47 PM, I wrote:
We have been discussing the importance of a unique random-seed
file each system. This is important even for systems 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
On 09/07/2010 10:21 AM, Marsh Ray wrote:
If anybody can think of a practical attack against the randomness
of a thermal noise source, please let us know. By practical I
mean to exclude attacks that use such stupendous resources that
it would be far easier to attack other elements of the
On 09/07/2010 11:19 AM, Perry E. Metzger wrote:
2) You can shield things so as to make this attack very,
very difficult.
I suspect that for some apps like smart cards that might be hard.
OTOH, it might be straightforward to detect the attempt.
We should take the belt-and-suspenders
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 07/31/2010 09:00 PM, Jerry Leichter wrote:
I wouldn't recommend this for high-value security, but then if you're
dealing with high-value information, there's really no excuse for not
having and using a source of true random bits.
Yes indeed!
On the question of what to do if we can't be
Hi Henrique --
This is to answer the excellent questions you asked at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587665#81
Since that bug is now closed (as it should be), and since these
questions are only tangentially related to that bug anyway, I am
emailing you directly. Feel free
On 07/29/2010 12:47 PM, Richard Salz wrote:
At shutdown, a process copies /dev/random to /var/random-seed which is
used on reboots. [1]
Actually it typically copies from /dev/urandom not /dev/random,
but we agree, the basic idea is to save a seed for use at the
next boot-up.
Is this a
On 08/01/2009 02:06 PM, Jerry Leichter wrote:
A while back, I evaluated a
technology that did it best to solve a basically insoluble problem: How
does a server, built on stock technology, keep secrets that it can use
to authenticate with other servers after an unattended reboot?
This
On 10/28/2008 09:43 AM, Leichter, Jerry wrote:
| We start with a group comprising N members (machines or
| persons). Each of them, on demand, puts out a 160 bit
| word, called a member word. We wish to combine these
| to form a single word, the group word, also 160 bits
| in length.
On 10/25/2008 04:40 AM, IanG gave us some additional information.
Even so, it appears there is still some uncertainty as to
interpretation, i.e. some uncertainty as to the requirements
and objectives.
I hereby propose a new scenario. It is detailed enough to
be amenable to formal analysis. The
Alas on 10/25/2008 01:40 PM, I wrote:
To summarize: In the special sub-case where M=1, XOR
is as good as it gets. In all other cases I can think
of, the hash approach is much better.
I should have said that in the special sub-case where
the member word has entropy density XX=100% _or_ in
On 10/24/2008 03:40 PM, Jack Lloyd wrote:
Perhaps our seeming disagreement is due to a differing interpretation
of 'trusted'. I took it to mean that at least one pool had a
min-entropy above some security bound. You appear to have taken it to
mean that it will be uniform random?
Thanks, that
On 09/29/2008 05:13 AM, IanG wrote:
My assumptions are:
* I trust no single source of Random Numbers.
* I trust at least one source of all the sources.
* no particular difficulty with lossy combination.
If I have N pools of entropy (all same size X) and I pool them
together with XOR,
On 10/24/2008 01:12 PM, Jack Lloyd wrote:
is a very different statement from saying that
lacking such an attacker, you can safely assume your 'pools of
entropy' (to quote the original question) are independent in the
information-theoretic sense.
The question, according to the original
On 09/20/2008 12:09 AM, IanG wrote:
Does anyone know of a cheap USB random number source?
Is $7.59 cheap enough?
http://www.geeks.com/details.asp?invtid=HE-280Bcat=GDT
For that you get a USB audio adapter with mike jack, and
then you can run turbid(tm) to produce high-quality randomness.
In 1951, John von Neumann wrote:
Any one who considers arithmetical methods of producing random digits
is, of course, in a state of sin.
That may or may not be an overstatement.
IMHO it all depends on what is meant by random. The only notion
of randomness that I have found worthwhile is the
On 07/23/2008 12:44 AM, Steven M. Bellovin wrote:
Niels Provos has a web page up with some javascript that automatically
checks if your DNS caching server has been properly patched or not.
http://www.provos.org/index.php?/pages/dnstest.html
It is worth telling people to try.
Those who
This is an important discussion
The threats are real, and we need to defend against them.
We need to consider the _whole_ problem, top to bottom. The
layers that could be subverted include, at a minimum:
-- The cpu chip itself (which set off the current flurry of
interest).
-- The boot
I quote from
http://www.washingtonpost.com/wp-dyn/content/article/2008/02/06/AR2008020604763_pf.html
By Ellen Nakashima
Washington Post Staff Writer
Thursday, February 7, 2008; A01
The seizure of electronics at U.S. borders has prompted protests from
travelers who say they now weigh
Hi Folks --
I have been asked to opine on a system that requires a
two-person login. Some AIX documents refer to this as
a common method of increasing login security
http://www.redbooks.ibm.com/redbooks/pdfs/sg245962.pdf
However, I don't think it is very common; I get only five hits
from
On 01/29/2008 11:34 AM, The Fungi wrote:
I don't think it's security theater at all, as long as established
procedure backs up this implementation in a sane way. For example,
in my professional life, we use this technique for commiting changes
to high-priority systems. Procedure is that two
On 12/23/2007 08:24 PM, ' =JeffH ' wrote:
2008: The year of hack the vote?
Shouldn't that be:
2008: Another year of hack the vote yet again?
..^^^...^
There is every reason to believe that the 2000 presidential
election was stolen. A fair/honest/lawful
On 12/13/2007 08:23 PM, Taral wrote:
On 12/12/07, John Denker [EMAIL PROTECTED] wrote:
Several important steps in the process must be carried out in
secret, and if there is any leakage, there is unbounded potential
for vote-buying and voter coercion.
I've done quite a bit of work
Hi Folks --
I was wondering to what extent the folks on this list have taken
a look the PunchScan voting scheme:
http://punchscan.org/
The site makes the following claims:
End-to-end cryptographic independent verification, or E2E, is a
mechanism built into an election that allows voters
For years, the Election Integrity Committee of the Pima County
Democratic Party has been trying to improve the security of the
elections systems used in local elections. The results include:
-- a dozen or so suggestions that they made were actually accepted
and implemented by the county.
--
On 07/10/2007 01:59 AM, Florian Weimer wrote:
It's also an open question whether network operators subject to
interception requirements can legally offer built-in E2E encryption
capabilities without backdoors.
I agree. It's a tricky question; see below
JI responded:
You probably meant
On 07/01/2007 05:55 AM, Peter Gutmann wrote:
One threat model (or at least failure mode) that's always concerned me deeply
about QC is that you have absolutely no way of checking whether it's working
as required. With any other mechanism you can run test vectors through it,
run
On 06/25/2007 08:23 PM, Greg Troxel wrote:
1) Do you believe the physics? (Most people who know physics seem to.)
Well, I do happen to know a thing or two about physics. I know
-- there is quite a lot you can do with quantum physics, and
-- there is quite a lot you cannot do with quantum
On 01/05/2007 10:53 AM, Paul Hoffman wrote:
You could take an IPsec stack and repurpose it down one layer in the
stack. At least that way you'll know the security properties of what you
create.
That is a Good Idea that can be used in a wide range of
situations. Here is some additional
On 12/22/2006 01:57 PM, Alex Alten wrote:
I'm curious as to why the cops didn't just pull the plugs right away.
Because that would be a Bad Idea. In a halfway-well-designed
system, cutting the power would just do the secret-keepers' job
for them.
It would probably
take a while (minutes,
Dave Korn asked:
Is it *necessarily* the case that /any/
polynomial of log N /necessarily/ grows slower than N?
Yes.
Hint: L'Hôpital's rule.
if P(x)==e^(2x)
That's not a polynomial.
x^Q is a polynomial. Q^x is not.
-
Andrea Pasquinucci wrote:
http://www.idquantique.com/products/quantis.htm
Quantis is a physical random number generator exploiting an elementary
quantum optics process. Photons - light particles - are sent one by one
onto a semi-transparent mirror and detected. The exclusive events
Hal Finney wrote in part:
... Attempts to embed sensitive secrets in credentials don't work because there
are no sensitive
secrets today. You could use credit card numbers or government ID numbers (like US SSN) but in
practice such numbers are widely available to the black hat community.
In the context of
0 occurs with probability 1/2
each other number from 1 to 2^{160}+1 happens with
probability 2^{-161}.
I wrote:
This ... serves to illustrate, in an exaggerated way, the necessity
of not assuming that the raw data words are IID (independent and identically
distributed).
this is clearly a probability distribution (with some technicalities
regarding issues of program lengths being glossed over here) as John
Denker says. However to go from this to a notion of entropy is more
questionable.
Not really questionable. If you have a probability, you have an
entropy
Ed Gerck wrote:
In Physics, Thermodynamics, entropy is a potential [1].
That's true in classical (19th-century) thermodynamics, but not
true in modern physics, including statistical mechanics. The
existence of superconductors and superfluids removes all doubt
about the absolute zero of
Aram Perez wrote:
* How do you measure entropy? I was under the (false) impression that
Shannon gave a formula that measured the entropy of a message (or
information stream).
Entropy is defined in terms of probability. It is a measure of
how much you don't know about the situation. If by
John Kelsey wrote:
As an aside, this whole discussion is confused by the fact that there
are a bunch of different domains in which entropy is defined. The
algorithmic information theory sense of entropy (how long is the
shortest program that produces this sequence?) is miles away from the
I wrote:
With some slight fiddling to get the normalization right, 1/2
raised to the power of (program length) defines a probability
measure. This may not be the probability you want, but it
is a probability, and you can plug it into the entropy definition.
John Kelsey wrote:
No, this isn't
Matt Crawford wrote:
I so often get irritated when non-physicists discuss entropy. The word
is almost always misused.
Yes, the term entropy is often misused ... and we have seen some
remarkably wacky misusage in this thread already. However, physicists
do not have a monopoly on correct
James A. Donald wrote:
The correct mechanism is exception handling.
Yes, I reckon there is a pretty wide consensus that exceptions
provide a satisfactory solution to the sort of problems being
discussed in this thread.
If caller has provided a mechanism to handle the failure, that
mechanism
David Wagner wrote:
This just shows the dangers of over-generalization.
One could make an even stronger statement about the dangers of
making assumptions that are not provably correct.
Of course, we have to decide which is more important: integrity,
or availability.
That is a false
Anne Lynn Wheeler wrote:
is there any more reason to destroy a daily key after it as been used
than before it has been used?
That's quite an amusing turn of phrase. There are two ways to
interpret it:
*) If taken literally, the idea of destroying a key _before_ it is
used is truly an
I forgot to mention in my previous message:
It is worth your time to read _Between Silk and Cyanide_.
That contains an example of somebody who thought really
hard about what his threat was, and came up with a system
to deal with the threat ... a system that ran counter to
the previous
Dave Howe wrote:
Hmm. can you selectively blank areas of CD-RW?
Sure, you can. It isn't s much different from rewriting any
other type of disk.
There are various versions of getting rid of a disk file.
1) Deletion: Throwing away the pointer and putting the blocks back
on the free
Ben Laurie wrote:
Good ciphers aren't permutations, though, are they? Because if they
were, they'd be groups, and that would be bad.
There are multiple misconceptions rolled together there.
1) All of the common block ciphers (good and otherwise) are permutations.
To prove this, it suffices
Travis H. wrote:
Part of the problem is using a packet-switched network; if we had
circuit-based, then thwarting traffic analysis is easy; you just fill
the link with random garbage when not transmitting packets.
OK so far ...
There are two problems with this; one, getting
enough
In the context of:
If your plaintext consists primarily of small packets, you should set the MTU
of the transporter to be small. This will cause fragmentation of the
large packets, which is the price you have to pay. Conversely, if your
plaintext consists primarily of large packets, you
I've been following this thread for a couple of weeks now, and so
far virtually none of it makes any sense to me.
Back on 10/12/2005 Travis H. wrote:
I am thinking of making a userland entropy distribution system, so
that expensive HWRNGs may be shared securely amongst several machines.
What
Jerrold Leichter mentioned that:
a self-
signed cert is better than no cert at all: At least it can be used in an
SSH-like continuity of identity scheme.
I agree there is considerable merit to a continuity of identity
scheme.
But there are ways the idea can be improved. So let's discuss
Victor Duchovni wrote:
So wouldn't the world be a better place if we could all agree on a
single such library? Or at least, a single API. Like the STL is for C++.
Yes, absolutely, but who is going to do it?
One could argue it has already been done.
There exists a widely available,
Adam Shostack wrote:
Here's a thought:
Putting up a beware of dog sign, instead of getting a dog.
That's an interesting topic for discussion, but I don't think
it answers Perry's original question, because there are plenty
of situations where the semblence of protection is actually a
Perry E. Metzger wrote:
We need a term for this sort of thing -- the steel tamper
resistant lock added to the tissue paper door on the wrong vault
entirely, at great expense, by a brilliant mind that does not
understand the underlying threat model at all.
Anyone have a good phrase in mind that
On 07/13/05 12:15, Perry E. Metzger wrote:
However, I would like to make one small subtle point.
... the use of widely known pieces of information about
someone to identify them.
Yes, there are annoying terminology issues here.
In the _Handbook of Applied Cryptography_ (_HAC_)
-- on page
I am reminded of a passage from Buffy the Vampire Slayer.
In the episode Lie to Me:
BILLY FORDHAM: I know who you are.
SPIKE: I know who I am, too. So what?
My point here is that knowing who I am shouldn't be a
crime, nor should it contribute to enabling any crime.
Suppose you
On 06/27/05 00:28, Dan Kaminsky wrote:
... there exists an acceptable solution that
keeps PC's with persistent stores secure. A bootable CD from a bank is
an unexpectedly compelling option
Even more compelling is:
-- obtain laptop hardware from a trusted source
-- obtain software from a
Ed Gerck wrote:
Let me comment, John, that thermal noise is not random
When did you figure that out? If you'd been paying attention,
you'd know that I figured that out a long time ago.
First of all, the phrase not random is ambiguous. I said
Some people think random should denote 100% entropy
Referring to http://www.apache-ssl.org/randomness.pdf
I wrote:
I just took a look at the first couple of pages.
IMHO it has much room for improvement.
David Wagner responded:
I guess I have to take exception. I disagree. I think Ben Laurie's
paper is quite good. I thought your criticisms missed
Ben Laurie wrote:
The point I am trying to make is that predictability is in the eye of
the beholder. I think it is unpredictable, my attacker does not.
I still cannot see how that can happen to anyone unless
they're being willfully stupid. It's like something out
of Mad Magazine: White Spy
John Kelsey wrote:
If your attacker (who lives sometime in the future, and may
have a large budget besides) comes up with a better model to
describe the process you're using as a source of noise, you
could be out of luck. The thing that matters is H(X| all
information available to the attacker),
Zooko O'Whielacronx wrote:
I would love to have an information-theoretic argument for the security
of my PRNG, but that's not what we have,
Yes, and I'd like my goldfish to ride a bicycle, but he can't.
The P in PRNG is for Pseudo, and means the PRNG is relying
on computational intractability,
Jerrold Leichter asked:
random number generator this way. Just what *is*
good enough?
That's a good question. I think there is a good answer. It
sheds light on the distinction of pseudorandomness versus
entropy:
A long string produced by a good PRNG is conditionally
compressible
I wrote:
A long string produced by a good PRNG is conditionally
compressible in the sense that we know there exists a
shorter representation, but at the same time we believe it
to be conditionally incompressible in the sense that the
adversaries have no feasible way of finding a shorter
I wrote:
Taking bits out of the PRNG *does* reduce its entropy.
Enzo Michelangeli wrote:
By how much exactly?
By one bit per bit.
I'd say, _under the hypothesis that the one-way
function can't be broken and other attacks fail_, exactly zero; in the
real world, maybe a little more.
If you said
I wrote:
If the problem is a shortage of random bits, get more random bits!
Florian Weimer responded:
We are talking about a stream of several kilobits per second on a busy
server (with suitable mailing lists, of course). This is impossible
to obtain without special hardware.
Not very special, as
Florian Weimer wrote:
Would you recommend to switch to /dev/urandom (which doesn't block if
the entropy estimate for the in-kernel pool reaches 0), and stick to
generating new DH parameters for each connection,
No, I wouldn't.
or ...
generate them once per day and use it for several connections?
OK, let me ask a more specific question. Actually, let me
put forth some hypotheses about how I think it works, and
see if anyone has corrections or comments.
0) I'm not sure the words Perfect Forward Secrecy convey what
we mean when we talk about PFS. Definition 12.16 in HAC suggests
Matt Crawford wrote:
Plus a string of log(N) bits telling you how many times to apply the
decompression function!
Uh-oh, now goes over the judge's head ...
Hadmut Danisch wrote:
The problem is that if you ask for a string of log(N) bits, then
someone else could take this as a proof that this
I wrote:
4) Don't forget the _recursion_ argument. Take their favorite
algorithm (call it XX). If their claims are correct, XX should
be able to compress _anything_. That is, the output of XX
should _always_ be at least one bit shorter than the input.
Then the compound operation XX(XX(...))
I wrote
the Bi are the input blocks:
(IV) - B1 - B2 - B3 - ... Bk - H1
(IV) - B2 - B3 - ... Bk - B1 - H2
then we combine H1 and H2 nonlinearly.
(Note that I have since proposed a couple of improvements,
but I don't think they are relevant to the present remarks.)
David Wagner wrote:
This
Jerry Leichter writes:
However ... *any* on-line algorithm falls to a Joux-style attack.
Hal Finney wrote:
... hashes that support incremental hashing, as any useful hash surely must,
If you insist on being able to hash exceedingly long strings
(i.e. longer than your storage capacity) here is a
I agree with 99% of what Hal Finney wrote. I won't repeat
the parts we agree on.
But let's discuss these parts:
how much harder?
Well, probably a lot. Finding a regular B2 collision in a perfect
160 bit hash compression function takes 2^80 work. Finding a double
collision like this is
Hadmut Danisch wrote:
It can be easily shown that there is no lossless
compression method which can effectively compress every possible
input.
OK.
... I need a book about computer science or encoding theory,
which explicitely says that this is impossible, in a way that a person
unexperienced in
Jerrold Leichter wrote:
... the comments I've seen on this list and elsewhere have been much
broader, and amount to QM secure bit distribution is dumb, it solves
no problem we haven't already solved better with classical
techniques.
Most of the comments on this list are more nuanced than that.
1) Here's an article from the New York Times.
The headline just about says it all. Reportedly
THEY want voice-over-internet users to pay for
the privilege of having their calls tapped.
The Call Is Cheap. The Wiretap Is Extra.
News article
http://news.bbc.co.uk/2/hi/americas/3528502.stm
says in part:
The BBC's Zaffar Abbas, in Islamabad, says it appears that US
investigators were able to unscramble information on the computers
after Pakistan passed on suspicious encrypted documents.
Enzo Michelangeli wrote:
Can someone explain me how the phishermen escape identification and
prosecution? Gaining online access to someone's account allows, at
most, to execute wire transfers to other bank accounts: but in these
days anonymous accounts are not exactly easy to get in any country,
J Harper [EMAIL PROTECTED] wrote:
This barely deserves mention, but is worth it for the humor:
Information Security Expert says SSL (Secure Socket Layer) is Nothing More
Than a Condom that Just Protects the Pipe
http://www.prweb.com/releases/2004/7/prweb141248.htm
To which Eric Rescorla replied:
Way back on 05/20/2004 Ivan Krstic wrote:
Michael O. Rabin lectures on hyper-encryption and provably
everlasting secrets.
...
View here: http://athome.harvard.edu/dh/hvs.html
To my surprise, there has been no follow-up discussion
on this list.
(Hint: Most people on this list will want to
Ian Grigg wrote:
The phishing thing has now reached the mainstream,
epidemic proportions that were feared and predicted
in this list over the last year or two.
OK.
For the first
time we are facing a real, difficult security
problem. And the security experts have shot
their wad.
The object
R. A. Hettinga wrote:
From: Tefft, Bruce [EMAIL PROTECTED]
...
Where Big Brother Snoops on Americans 24/7
By TERESA HAMPTON DOUG THOMPSON
...
Although employees who work in the building are supposed to keep their
presence there a secret, they regularly sport their DARPA id badges around
their
] Thursday 25 December 2003, 17:13 Makka Time, 14:13 GMT
]
] Saudis swoop on DIY bomb guide
]
] Authorities in the kingdom have arrested five people after
] raiding computer shops selling compact disks containing
] hidden bomb-making instructions, a local newspaper reported
] on Thursday.
]
]
91 matches
Mail list logo
