Cryptography-Digest Digest #237, Volume #10 Tue, 14 Sep 99 22:13:03 EDT
Contents:
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out ([EMAIL PROTECTED])
Re: Ritter's paper (Terry Ritter)
Re: Cryptographic PRNG (jerome)
Re: Mystery inc. (Beale cyphers) (sha99y00000)
Re: Make a point on KRYPTOS ("Douglas A. Gwyn")
Re: Can you believe this?? (jerome)
Re: Can you believe this?? (jerome)
Re: Size of DH exponent & modulous?? ("Roger Schlafly")
Re: Mystery inc. (Beale cyphers) ("Douglas A. Gwyn")
Re: ti83 encryption ([EMAIL PROTECTED])
Re: Cryptographic PRNG ([EMAIL PROTECTED])
Re: Ritter's paper (David Wagner)
Re: Can you believe this?? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Wed, 15 Sep 1999 00:21:17 GMT
Here's an interesting email exchange between myself and Steve Schear
who (among other things) proposes an alternative type of "perfect
crime."
>--- Steve Schear <[EMAIL PROTECTED]> wrote:
>>
>> ...much deleted....
>>
>> > E-cash in a world without data havens would
>> >probably feature payer-only anonymity of the sort
>> >Deutsche Bank experimented with. Admittedly,
>> >payer-only anonymity could be transformed to full
>> >anonymity, with e-cash launderers operating
>> >"remailer" style -- acting as middlemen, and
>> >expunging records immediately after transmitting
>> >e-cash. However, launderers who did this would
>> >be vulnerable to sting operations where
>> >government "launder-narcs" posed as criminals
>> >needing money-laundering services. Payer-only
>> >anonymity ensures that the launderer would not
>> >know the identity of the paying party (a launder-
>> >narc), but the launder-narc would have
>> >incontrovertible proof of the launderer's crime.
>> >This sort of activist enforcement would not
>> >involve banning encryption or inspecting private
>> >messages.
>>
>> I think you misunderstand the Know Your Customer
>> requirements rules and
>> their widespread lack of enforcement outside the
>> G10. As you note, the
>> remailer doesn't know the identity of the payer and
>> so couldn't know source
>> of the funds. Ergo, no crime. Worldwide the standard
>> to which law
>> enforcement is held in pursing these matters against
>> financial institutions
>> is much higher than you assume. One has only to look
>> at the Carlos Salinas
>> affair with Citibank and the recent BNY russian
>> connection recently in the
>> news. You haven't heard of any indictments and you
>> probably won't.
>> Plausible deniability works and so will anonymous
>> cash remailers and
>> intermidiaries for digital cash transactions.
>>
>> --Steve
>>
>
>I am aware that Government regulators tend to look the other way at
>money laundering today. This makes sense because, to a great extent,
>odious regimes that rule without the consent of the people rely on
>money laundering to keep their grip on power. The more the
>kleptocrats' shenanigans are exposed to the public eye, the more
>ridiculous they look, and the higher chance of their being overthrown.
>
>So, you are right that money laundering is widely tolerated. Today.
>
>My contention is that if there was the technology to commit perfect
>crimes, global public opinion would swiftly turn against the
>e-launderers who abetted it.
I think it would depend upon whom the initial 'perfect crimes' were
committed. I dare say that if Saddam were the successful target of an
assassination for hire plot using anonymous money most of the western
public would just shrug and say good riddance, but the government elite
would not be so dismissive. There is substantial frustration by many
global citizens that many governments and their minions routinely
violate the
basic human rights of their citizens and that, for economic and
political reasons, their own democratic governments are either powerless
to stop
the carnage or do so only after thousands or even tens of thousands are
killed. If a 'democratic' means of 'encouraging' an end to these
criminals were
easily accessible to the average Netizen I believe enough would
participate to make this a new global political force to be recconned
with.
As you may know Jim Bell is serving time for minor offense
Substantially because he penned his Assassination Politics tome,
describing the way
in which one such anonymous betting pool might operate. Another, Carl
Johnson is also serving time related to his comic endorsement of Bell's
plan.
>I think of the current "private banking"
>regime of money laundering as a sort of gentleman's agreement. Private
>bankers will help criminals do their thing, but only up to a point.
>And the criminal always runs the risk of the private banker exposing
>his or her identity to the authorities.
>
>Okay, maybe not the master criminal's identity, but his agent's. At
>some point there's usually some kind of face to face contact.
>
>E-laundering would be fundamentally different. Here, the shady
>middleman would not know any identifying information about the parties
>she is assisting. It would all done by servers, left mostly
>unattended. Even if the sysadmin of the e-money-laundry wanted to help
>the authorities, she could not. Thus, the potential for evil is
>greatly expanded.
Or the potential good. See my comments above.
>
>Imagine this. Terrorists announce that they have planted a big bomb in
>an important heavily-populated building somewhere in the world. Unless
>50 million anonymous dollars are posted to such and such newsgroup,
>encrypted with such and such key, within half an hour, the bomb goes
>off. The money can come from anywhere, as long as it clears. The
>leaders of the first world refuse to negotiate with the terrorists.
>The bomb goes off and hundreds of people die. A week later the
>terrorists post another message asking for money (digitally signed so
>that there can be no doubt that this is the same group of bad guys).
>
>Plausible deniability sounds pretty feeble at this point. They don't
>call it perfect crime for nothing.
Such crimes can already be committed without anonymous digital cash.
Instead of the above scenario they merely ask that an leading U.S.
corporation (e.g., Microsoft, Intel or Cisco) announce dramatically
lower quaterly results. The criminals have been buying up put options or
indexes over several months using otherwise normal accounts under phoney
names.
The announcement causes a significant price decline and the criminals
cash
out their positions. Tracing them down could be on a scale comperable
with
the digital cash scenario.
>
>Thanks for the feedback.
>
>Thomas
>
>PS I won't post your part of this exchange without your go-ahead, but
>I would like it if you would. This touches on the heart of why I
wrote
>my original post in the first place.
Please feel free if you include my current response as well.
--Steve
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Ritter's paper
Date: Tue, 14 Sep 1999 23:58:13 GMT
On Tue, 14 Sep 1999 20:29:57 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[...]
>Extensive past cryptanalytic research does not, as you correctly note,
>_prove_ a block cipher unbreakable, but it does reduce the likelihood
>of the existence of a break likely to be known to, or able to be found
>out by, certain classes of adversary.
You have made an assertion, not a summary of the known reality. We do
not know the likelihood of any break. And, if our Opponents have a
break, no amount of cryptographic research is going to change the
probability of that reality. The only interaction of interest is
between the cipher and The Opponent, and the Opponents are not
talking. We do not have the evidence to discuss either strength or a
probability of a break. We cannot even collect data which would
foster academic inquiry into the issue.
>(That the history of
>cryptography is replete with systems that have been proposed for
>serious use, but which had serious and obvious flaws, as Bruce noted,
>is surely a fact beyond dispute.)
Yes. But these data do not imply what you think they do. They have
shown weakness; they do not imply strength in the remaining ciphers.
>A new design may be relatively untested, and lack this - admittedly
>limited - source of at least partial confidence.
I would say that, in cryptography, partial confidence is no confidence
at all.
>On the other hand, as
>you point out, an adversary has had less opportunity to study a novel
>design than one that has become the "standard of the industry", and if
>few people are using it, it may not be worth an adversary's while to
>study the design in detail.
>
>You did mention multiciphering, but because you did not (appear to?)
>acknowledge that the point of view you were criticizing also had some
>validity,
I have no idea what you are talking about here. The points which you
bring up in support of "that point of view" are in themselves invalid.
>even if it is imperfect and incomplete, you did not suggest
>what I feel is the only rational way to employ novel cipher designs
>when security is the primary object: in conjunction with the
>well-tested and established designs that Mr. Schneier advocates and
>recommends.
My article was a specific response to the earlier column which
essentially said that new cryptography was bad cryptography. My
article addresses that issue, and apparently you agree that it needed
to be said. But, of the two of us, one of us actually said it, and
one of us stood in the background and whines that it was not said just
right. Well, maybe I'll do better next time.
>Simply because one point of view is partly wrong doesn't mean the
>exact opposite must be completely right. And since that is such a
>common fallacy, usually both sides in a dispute will tend to fall for
>it, and as soon as those on one side have the opportunity to poke a
>few holes in an argument for another point of view, they will feel
>free to ignore it completely. This is why, when advocating a new point
>of view, it is important to be aware of where the old point of view is
>valid, so that what one proposes is free of error; it is not a matter
>of politeness to adherents of the older view, it is to avoid obvious
>mistakes that will prevent one's valid new ideas from being heard.
I am aware that the old point of view is fundamentally flawed and
scientifically invalid. It is *not* almost valid. It is *not* partly
right. It is *not* right in practice. It is just wrong.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Cryptographic PRNG
Date: 15 Sep 1999 00:16:24 GMT
Reply-To: [EMAIL PROTECTED]
i looked at your code and if im not wrong
reSeed read /dev/random and use the result as a twofish key
prngOutput() read /dev/urandom, encrypt the result with twofish and
put it in a buffer.
2 things:
- the result of /dev/urandom is as random that Encrypt(/dev/urandom)
if the key is known by the attacker. the encryption doesnt produce
any random.
- if the key is unknow to the attacker, he can't predict
the output of prngOutput except if it break twofish or the key.
assuming /dev/random unpredictable and /dev/urandom predicatable.
your algorithm take /dev/urandom and stretch <keylength> unpredictable
bits over the length of your prngOutput().
in your implementation, you will have just <keylength> unpredictable
bits (256 in your case) even if you produce a 1MB output
or 1GB output.
in fact a 1GB output will have only 1 unpredictable bit for
33554432 (2^25=2^33-2^8) predictable bits :)
random isnt so easy :)
-- jerome who is trying to implement one
On Mon, 13 Sep 1999 21:26:32 -0400, [EMAIL PROTECTED] wrote:
>
>I have created a PRNG for the UNIX o/s and I was hoping that someone
>would tear apart my code, and tell me what I'm doing wrong (or right, if
>the case may be). The code is very easy to understand, but if you are
>not familliar with the UNIX operating system, just remember that
>/dev/random contains high quality entropy (or so they say), that is
>suitable for cryptographic uses, and /dev/urandom is like a prng (not
>made for cryptographic uses), is basically Hash([old hash], [counter],
>[any new entropy in /dev/random]). The only problem I can see with it,
>is if /dev/random and/or /dev/urandom was corrupted (in any way). I
>would be interested to hear some comments....
>
>[------Begin Code
>#include "twofish.h"
>
>#include <unistd.h>
>#include <sys/stat.h>
>#include <fcntl.h>
>#include <memory.h>
>
>
>void reSeed(TWOFISH_context *ctx)
>{
> char key[32];
> int i = 0, random = 0;
>
> random = open("/dev/random", O_RDONLY);
>
> for (i = 0; i < 32; i++)
> read(random, &key[i], 1);
>
> close(random);
>
> twofish_setup(ctx, sizeof(key), key);
>
> memset(key, 0, sizeof(key));
>}
>
>
>void prngGetOutput(unsigned char *output, TWOFISH_context *ctx)
>{
> char buffer[16];
> int urandom = 0, i = 0;
>
> urandom = open("/dev/urandom", O_RDONLY);
>
> for (i = 0; i < 16; i++)
> read(urandom, &buffer[i], 1);
>
> close(urandom);
>
> twofish_encrypt(ctx, buffer, output);
>
> memset(buffer, 0, sizeof(buffer));
>}
>
>void prngOutput(unsigned char *buffer, unsigned int len)
>{
> unsigned int i = 0, a = 0;
> unsigned char tmpBuff[16];
> TWOFISH_context ctx;
>
> reSeed(&ctx);
>
> while (i < len)
> {
> prngGetOutput(tmpBuff, &ctx);
> if ((len - i) > 8)
> {
> for (a = 0; a < 8; a++)
> buffer[i+a] = tmpBuff[a];
> i += 8;
> }
> else
> {
> for (a = 0; a < (len - i); a++)
> buffer[i+a] = tmpBuff[a];
> i = len;
> }
>
> }
> memset(ctx.keys, 0, sizeof(ctx.keys));
> memset(ctx.s_box, 0, sizeof(ctx.s_box));
>}
>
------------------------------
Date: Wed, 15 Sep 1999 00:15:50 +0100
From: sha99y00000 <[EMAIL PROTECTED]>
Subject: Re: Mystery inc. (Beale cyphers)
[EMAIL PROTECTED] wrote:
> I see you are posting from the UK and I don't know what your
> options are there. However, in the US, the Interlibrary Loan
> department of any public library can get copies of articles from other
> libraries. Perhaps this service is available in the UK as well.
>
> Hammer, Dr. Carl, "Signature Simulation and Certain Cryptographic
> Codes", Communications of the ACM, January 1971, Volume 14,
> Number 1, pp. 3-14.
I'll try tomorrow and see what my library can offer. I just thought that
these papers would have been freely on the net for a wider feedback.
>
> By the way, can you turn off the <.html> coding when you post? It
> would make your posts easier to read.
Right! I've done that. Sorry for the inconvenience. I was wondering why
some messages used > and others were enclosed by blue lines. I'm new to
all this.
sha99y
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Make a point on KRYPTOS
Date: Tue, 14 Sep 1999 23:36:10 GMT
Jim Gillogly wrote:
> There are certainly no ground rules cut into the sculpture.
However, the cryptographer seems to have intentionally
chosen systems and ciphertext quantities that can be
broken with pencil-and-paper (and perserverance, and luck).
So it seems that it was intended to be a "fair" challenge.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Can you believe this??
Date: 15 Sep 1999 00:23:46 GMT
Reply-To: [EMAIL PROTECTED]
but /dev/random is blocking when the entropy isnt there...
important to know :)
and you can still use /dev/urandom for challenge, because as
far as i know they don't need to be cryptographically random
On Tue, 14 Sep 1999 14:44:21 -0700, Eric Lee Green wrote:
>
>See what I mean? I'd rather know this TODAY than six months from now!
>
>Taking your advice, and will use /dev/random to seed Ocotillo instead of
>using /dev/urandom directly as a PRNG.
>
>--
>Eric Lee Green http://members.tripod.com/e_l_green
> mail: [EMAIL PROTECTED]
> ^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Can you believe this??
Date: 15 Sep 1999 00:29:16 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 14 Sep 1999 15:18:50 -0400, Anton Stiglic wrote:
>
>Why publish the source?
>
> 2. There is always a way to get the source. If it's written
> in C, there are decompilers out there. Even if decompilation
> produces assembly language, that's enaugh. Java, even
> easier, etc.. etc...
if you use a better tech than the competitor, with the source
it can simply recode it.
ok it can disasm your exec but it is much harder.
just get an ike implementation and try to analize a part such as
the diffe-hellman computation... and see the amount of time involved.
but ok if you don't have 'trade secret', a public examination allows
to find bug and weakness much more easily.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Size of DH exponent & modulous??
Date: Tue, 14 Sep 1999 16:51:54 -0700
Eric Lee Green <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Peter Gunn wrote:
> > Would a 512bit prime, and 256bit values for x and y suffice?
> > Similarly, any suggestions for key lengths of 128bits and 256bits?
>
> For a uniform distribution you need a range for x and y that is (P-1) in
> size. That is, x and y should probably have the same number of bits as
> the prime.
Actually, the private key can be much smaller. In DSA, the private
key is only 160 bits.
> According to at least one source that I came across, breaking
> Diffie-Hellman may be reducible to the same order as breaking the
> factoring problem. A 512-bit number was recently factored. Thus a field
> size of 1024 bits is probably a better choice nowdays than a 512-bit
> field size.
By the best methods known, Diffie-Hellman is harder than factoring.
The largest discrete log (for generic prime field) that has been solved
is 283 bits. (Announced in Eurocrypt '98)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mystery inc. (Beale cyphers)
Date: Wed, 15 Sep 1999 00:13:04 GMT
Curt Welch wrote:
> ... So the natural assumption everyone makes is that the two unbroken
> cyphers were probably the same...
> But, Jim Gillogly's discovery of the alphabetic strings (as far as I know
> no he was the first to publish this) changed all that. It means that if
> the #1 cypher is a real cypher -- i.e. it somehow decodes to a real message
> -- then it is most likely not a simple book cypher. i.e., looking for the
> "right" document to decode it with is a waste of time.
If those strings are causal, it means is that the DOI, used exactly
that way, *is* the right key document (perhaps misapplied, if Beale
is not a hoax, or correctly applied, if it *is* a hoax).
If this had dated from the ASCII era, I would suspect that the
alphabetic stretch was just a repeated character such as " ", and the
book cipher had been superenciphered by adding an increasing set of
numbers, such as the letter number within the original plaintext.
But I don't think there is any *alphabetic* letter that is likely to
be repeated that much in the plaintext ("X" maybe, but why?)
> It is however, still very likely that the #1 cypher is a simple multiple
> substitution cypher. That is, each number in the cypher text maps to a
> single letter. And each number maps to the same letter each time it's used
> - but multiple numbers are used for the same letter (hence multiple
> substitution).
The standard term is "simple substitution with variants".
> So, I have been using the term "Key" in my posts to refer not the to
> document (like the DOI) which is used to decode the message, but rather the
> table of letters and numbers which must be used to decode the message.
Remember that the key was (according to the story) intended to be sent
later; decryption of B2 showed what form one key took, and it is
reasonable to think that what was intended to be sent in the "here's
the key" letter would be a description of the general process used,
and the identities of (or copies of) the particular documents used.
Without finding a key document, it's pretty hopeless -- there is too
little information in B{1,2,3} to be able to unambiguously crack
without finding the key document. Fortunately, for B1 it seems to
be DOI, or rather, the DOI variant used with B2..
[If you want to try cracking a SSWV message not based on a book cipher,
try the first large Zodiac cipher. (It has been cracked.) Then tackle
the second large Zodiac cipher. (It has not been cracked.) If you do
crack it, you might solve a longstanding serial-killer murder mystery.]
> ... So, in the encoding process, you may decide to encode one word
> (like "the") using numbers from the say the second line. Then the
> next word (like "gold") is encoded with numbers from the third line, ...
> And what do you see when you decode this segment of cyhper text with
> the DOI key? "BBBCCCCDD" (one of the Gillogly stirngs ...)
That is a valuable observation.
> ...you start back at the top of the table, and encode a letter from
> the frist line, then the next letter is encoded with a number from
> the second line, then the third, etc. ... So what does this end up
> looking like when you decode it with the wrong key (i.e the DOI)?
> "ABCDEFGHIIJ..."
Ditto.
It's the right key, applied the wrong way.. That's the usual sort
of thing that happens in cryptanalysis when one makes a wrong
assumption that contains *some* truth but gets the details wrong.
Thanks for providing the further elaboration.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ti83 encryption
Date: Tue, 14 Sep 1999 21:17:45 -0400
Ah yes...I didn't take the time to look at your TI basic. Then your algorithm should
be
for the most part secure.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cryptographic PRNG
Date: Tue, 14 Sep 1999 21:34:28 -0400
jerome wrote:
> i looked at your code and if im not wrong
> reSeed read /dev/random and use the result as a twofish key
> prngOutput() read /dev/urandom, encrypt the result with twofish and
> put it in a buffer.
Yep. The original code (not of my own doing, rather Yarrow), called for
Encrypt(Counter) rather than /dev/urandom. Instead of giving a 100% known
plaintext, I simply used /dev/urandom. It is allways going to have a
different output, but it really doesn't increase or decrease the security as
far as I can see (since you are giving known plain text anyway).
> 2 things:
>
> - the result of /dev/urandom is as random that Encrypt(/dev/urandom)
> if the key is known by the attacker. the encryption doesnt produce
> any random.
As far as I know most all cryptographic PRNGs work off of block ciphers.
This method is basically a modified Yarrow. Yarrow grabs entropy, and uses
it for a key. The key is used to encrypt a counter. The output is secure as
long as the seed to the generator (the original entropy that it took) is not
given away. This one does basically the same thing. It takes entropy from
/dev/random and uses it for a key. Instead of encrypting a counter, I use
/dev/urandom. Same effect...but you are not giving out a 100% known
plaintext. (I believe this is also how PGP generates random numbers....)
> - if the key is unknow to the attacker, he can't predict
> the output of prngOutput except if it break twofish or the key.
That's the idea behind these PRNGs...
> assuming /dev/random unpredictable and /dev/urandom predicatable.
> your algorithm take /dev/urandom and stretch <keylength> unpredictable
> bits over the length of your prngOutput().
>
> in your implementation, you will have just <keylength> unpredictable
> bits (256 in your case) even if you produce a 1MB output
> or 1GB output.
This is one of the reasons I posted the code on this board. Are you 100%
sure that outputs are not random? Wouldn't that mean a serious break on the
algorithm?
> in fact a 1GB output will have only 1 unpredictable bit for
> 33554432 (2^25=2^33-2^8) predictable bits :)
hrm...I don't see how my method is any different from what yarrow or PGP
does...what should I be doing different?
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Ritter's paper
Date: 14 Sep 1999 17:35:45 -0700
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (David Wagner) wrote:
> >Let f(R) be the probability that we apply the resources specified
> >by R to cryptographic design and analysis, and yet the adversary still
> >manages (somehow) to break our cipher.
>
> No, no, no we can't. We might calculate the economic disaster
> which would result from breaking (and those results would be:
> disaster for the AES approach; a regrettable transient loss in mine),
> but we cannot calculate the probability that a cipher will fail.
Thanks for the feedback; it's helpful. But I must admit I disagree
with the above. It's probably my fault for not making things clearer.
1. We might not be able to calculate the quantity f(R), but that's
irrelevant to my argument; I don't care what the value of f(R) is.
My argument indicates that, no matter what the values of f(R) are, the
single-cipher strategy is preferred to the multi-cipher strategy. All
that is required is that f(R) be well-defined, not that it be easy to
calculate.
By analogy: let N = 10^(10^(10^(10^10))), and let M be the N-th digit
of pi; despite the fact that M is probably very hard to calculate, it
is still well-defined. This shows that just because a quantity is hard
to calculate in practice doesn't necessarily mean it is ill-defined.
2. One must be a bit careful in interpreting the probability space here.
The probability space is given by the subjective choices of the designers
and analysts; the sample space is whether or not the resulting cipher is
secure. In other words, if we let X = 1 if the cipher is insecure and 0
otherwise, then X is a random variable, and f(R) = Prob[X = 1].
Maybe the following will help make the definition of f(R) a bit more
explicit. One can imagine running the following thought experiment many
times: hire some cryptographers to design the best cipher they can with
resources R, and then ask some "oracle" whether the result is secure.
Then the idea is that the probability f(R) is the fraction of times that
the resulting cipher is insecure.
(In practice, it may be too difficult to check whether the result is
secure, but in principle, we know there is some truth of the matter
about whether the cipher is secure, so the value f(R) is well-defined.)
3. I hope the above comments make it clearer why f(R) < f(R') when R > R'.
It just says that, if we run the above thought experiment with more
resources, we'll see fewer insecure ciphers.
This _is_ an assumption about humans. But if the assumption is wrong,
doing cryptanalysis would be an actively harmful activity, because it
would confuse us more often than it will help us -- and I doubt that
too many folks want to try to make the case for _that_ result.
4. By the way, your note has helped me to recognize and clarify several
unstated assumptions. Thank you.
First: I have not considered the workfactor required to read traffic;
if the adversary does not know which cipher each message was encrypted
in, then the adversary's workfactor may be as much as N times higher
in a multi-cipher scenario. I believe this reasoning can be made
precise with a bit more work.
Second: as you say, I have not compared the resources required for the
adversary to analyze the ciphers. A good point; thank you. It is not
immediately clear to me which approach this factor would favor, but if
we assume in practice that the adversary's analysis resources are much
larger than our own, it may not matter. I do not know whether this can
be modeled in my model, or whether it is an fundamental limitation of
my model.
I do agree that these are fundamental premises which must be assumed
if the conclusion of my argument is to be valid. This suggests that
in practice we should be looking carefully at those assumptions to see
whether they hold in the real world or not.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can you believe this??
Date: Tue, 14 Sep 1999 21:19:59 -0400
jerome wrote:
> but /dev/random is blocking when the entropy isnt there...
> important to know :)
Ahh yeah...I tested it...It just kinda hangs. There has got to be a read
from the device that will timeout....
> and you can still use /dev/urandom for challenge, because as
> far as i know they don't need to be cryptographically random
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
