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 tr
-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 wit
On 09/15/2013 03:49 AM, Kent Borg wrote:
> When Bruce Schneier last put his hand to designing an RNG he
> concluded that estimating entropy is doomed. I don't think he would
> object to some coarse order-of-magnitude confirmation that there is
> entropy coming in, but I think trying to meter entro
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
This discussion will progress more smoothly and more rapidly
if we clarify some of the concepts and terminology.
There are at least four concepts on the table:
1) At one extreme, there is 100% entropy density, for example
32 bits of entropy in a 32-bit word. I'm talking about real
physics
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-strengt
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 t
On 09/08/2013 12:08 PM, Perry E. Metzger wrote:
> I doubt that safety is, per se, anything the market demands from
> cars, food, houses, etc.
I wouldn't have said that. It's a lot more complicated than
that. For one thing, there are lots of different "people".
However, as a fairly-general rule,
-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 Enforcemen
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) Brea
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 instal
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
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 a
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
On 09/05/2010 08:27 PM, Jerry Leichter wrote:
> If you think about the use of randomness in cryptography, what matters
> isn't really randomness - it's exactly unpredictability.
Agreed.
> This is a very
> tough to pin down: What's unpredictable to me may be predictable to
> you,
It's easy to
On 08/26/2010 11:34 PM, Thomas wrote:
> Luckily /dev/random is re-seeded during run-time.
I would have said something different: *IF* you are
lucky, then /dev/random gets reseeded during run time.
> So even if you do
> a roll-back of a system and the new input it non-deterministic it will
> ge
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 leadin
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 b
On 07/31/2010 08:49 AM, Henrique de Moraes Holschuh wrote:
> the best way of fixing a Debian
> system to be more secure as far as the quality of the randomness used by a
> random user application will be, AFAIK, is to simply get a medium or high
> bandwidth TRNG,
Yes indeed!
> I don't have
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 to
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 go
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 le
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_ i
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
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, t
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 origina
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
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-280B&cat=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
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.
>>
>
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 rom
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
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 tw
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 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.
>
&
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 voter
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.
-- th
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 devi
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 ongoing/continuo
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/18/2007 03:13 PM, David Wagner wrote:
> In article <[EMAIL PROTECTED]> you write:
>> The /definition/ of entropy is
>>
>> sum_i P_i log(1/P_i) [1]
>>
>> there the sum runs over all symbols (i) in the probability
>> distribution, i.e. over all symbols in the ensembl
On 01/17/2007 06:07 PM, Allen wrote:
> The whole issue of entropy is a bit vague for me - I don't normally work
> at that end of things - so could you point to a good tutorial on the
> subject, or barring having a reference handy, could you give an overview?
Entropy is defined in terms of probab
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 deta
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.
---
James A. Donald wrote:
>
> And if you want to obtain noise from quantum
> indeterminacy, shot noise is much more convenient.
> Instead of photons going through a half silvered mirror,
> and randomly being reflected or not, you rely on
> electrons randomly winding up at the base or the
> collecto
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
Hadmut Danisch wrote:
is anyone aware of a general and precise definition of the term
'principal' (as a noun) in the context of security?
Its use in security does not AFAICT differ from its use in
other contexts, notably law and finance.
I don't see why it is necessary to look beyond an ordin
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.
The
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
> distr
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 entrop
Erik Zenner wrote:
0 occurs with probability 1/2
each other number from 1 to 2^{160}+1 happens with
probability 2^{-161}.
Is anyone aware of whether (and where) this was
discussed in the literature, or what other approaches are taken?
This particular problem is contrived or at least exagg
osen input program will output that string.
So 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
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,
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
infor
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
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 u
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 dicho
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
>> Yet, I agree it is poor design to [exit] in a library.
I agree, it is a poor design.
Werner Koch retorted:
I disagree strongly here. Any code which detects an impossible state
or an error clearly due to a programming error by t
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 conventiona
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 inge
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 lis
[EMAIL PROTECTED] wrote:
From what I understand simple quantum computers can easily brute-force attack
RSA keys or other
types of PK keys.
My understanding is that quantum computers cannot "easily" do anything.
As the saying goes:
"We can factor the number 15 with quantum computers. We
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 t
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, yo
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 random
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 e
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 discu
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, freely
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
cost-ef
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 38
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 k
On 07/03/05 15:19, Dan Kaminsky wrote:
> So the funny thing about, say, SHA-1, is if you give it less than 160
> bits of data, you end up expanding into 160 bits of data, but if you
> give it more than 160 bits of data, you end up contracting into 160 bits
> of data. This works of course for any
On 07/01/05 13:08, Charles M. Hannum wrote:
Most implementations of /dev/random (or so-called "entropy gathering
daemons") rely on disk I/O timings as a primary source of randomness.
... I believe it is readily apparent that such exploits could be
written.
So don't do it that way.
Vastly b
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 tru
Steven M. Bellovin wrote:
Are there any commercial link-layer encryptors for Ethernet available?
I know that Xerox used to make them, way back when, but are there any
current ones, able to deal with current speeds (and connectors)?
Several people have made suggestions involving IPsec,
which were
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
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),
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 accep
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 mis
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, not
Ben Laurie wrote:
Given recent discussion, this is perhaps a good moment to point at a
paper I wrote a while back on PRNGs for Dr. Dobbs, where, I'll bet, most
of you didn't read it.
http://www.apache-ssl.org/randomness.pdf
I just took a look at the first couple of pages.
IMHO it has much room f
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
represe
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 in
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
Enzo Michelangeli wrote:
>
> This "entropy depletion" issue keeps coming up every now and then, but I
> still don't understand how it is supposed to happen.
Then you're not paying attention.
> If the PRNG uses a
> really non-invertible algorithm (or one invertible only with intractable
> complexity
Udhay Shankar N wrote:
I just got a batch of spam: perfectly justified blocks of random-looking
characters. Makes me wonder if somebody is trying to train Bayesian
filters to reject PGP messages.
Another hypothesis: Cover traffic, to defeat traffic analysis.
The procedure: send N copies. N-M o
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, a
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?
Fredrik Henbjork wrote:
Alice has:
1. A system which does processing of encrypted network streams.
Alice wants the following from Bob:
2. A test system for the processing system in 1. This system is going
to be used to decide if the processing system in 1 is working
(processing) as it should.
Thi
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
_break-back
Eric Rescorla wrote:
Uh, you've just described the ephemeral DH mode that IPsec
always uses and SSL provides.
I'm mystified by the word "always" there, and/or perhaps by
the definition of Perfect Forward Secrecy. Here's the dilemma:
On the one hand, it would seem to the extent that you use
ephemer
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
>> 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 Wa
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(...)) sh
1 - 100 of 117 matches
Mail list logo
