Cryptography-Digest Digest #241, Volume #10 Wed, 15 Sep 99 14:13:03 EDT
Contents:
Re: Random and pseudo-random numbers (Alwyn Allan)
one time pad ([EMAIL PROTECTED])
Re: Newbie needs help (David A Molnar)
Re: OBJECT IDENTIFIER for HMAC-SHA1-96 and HMAC-MD5-96???? ("Richard Parker")
Re: one time pad (Anton Stiglic)
Re: one time pad (Anton Stiglic)
Re: one time pad (Alex)
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out (Daniel James)
Re: General encryption question ("Dr.Gunter Abend")
Re: Can you believe this?? (Paul Koning)
Re: Mystery inc. (Beale cyphers) ("Douglas A. Gwyn")
Re: one time pad ("Richard Parker")
Re: Ritter's paper ("Douglas A. Gwyn")
Re: compression and encryption (Tim Tyler)
Re: Second "_NSAKey" (David Wagner)
Re: Second "_NSAKey" (Peter Pearson)
Re: Second "_NSAKey" (Medical Electronics Lab)
Re: Ritter's paper ("Trevor Jackson, III")
Re: one time pad (Anton Stiglic)
Re: Mathematical models and encryption (Anton Stiglic)
Re: Ritter's paper (John Savard)
Re: one time pad (Alex)
----------------------------------------------------------------------------
Date: Wed, 15 Sep 1999 10:09:37 -0400
From: Alwyn Allan <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Mok-Kong Shen wrote:
> Could someone tell what is the rough demand of random bits (per
> unit of time) for generating session keys in certain typical
> environments, e.g. for a small office, for a branch of a bank,
> etc.? I like to know the order of magnitude of such values.
Using current practices, I have tried to estimate an upper bound on RNG
demands. Assume that a bank/brokerage has a server cluster handling 600 SSL
connections per second (52 million/day). They would likely use an IPivot
CD8000 SSL Accelerator (or something like it). Assume further that every
connection initiates a session, and thus requires new keys. Assume further
that the most secure algorithm (3-DES) is used for all of them, requiring
168-bit keys. That yields 100,000 bits/second.
The IPivot CD8000 contains at least one Rainbow CryptoSwift chip that claims
1,000,000 bits/sec for its RNG. This is obviously not the bottle-neck.
I have a paper design for an 8,000,000 bit/sec hardware RNG. Unless I can
find some use for it in the world, it will remain on paper.
AlwynAllan
http://www.delanet.com/~apa/orb/
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
======== Over 73,000 Newsgroups = Including Dedicated Binaries Servers =======
------------------------------
From: [EMAIL PROTECTED]
Subject: one time pad
Date: Wed, 15 Sep 1999 14:33:25 GMT
I am currently taking a security class and my
professor has asked us to break two messages
encrypted with the same one time pad.
The one-time pad used was generated with a
pseudo-random number generator, with output values
ranging from 0 to 127.
I am trying to think of an efficient way to attack
this problem but so far all I can think of is
generating all possibilities for the first
character for both texts and then generating all
possibilities for the second character. In my
mind I would place these results on two seperate
"wheels" and turn them and see if I get any
matches. BUT to compute both texts will require
more CPU power than I have. I was planning on
writing this program in C++.
I was wondering if anyone out there knew of a
better way to attack this.
For those interested the assignment is online
http://banshee.eas.muohio.edu/~duffm/san610/
NOTE: I am not asking for someone to decrypt the
text for me, I am just seeing if I am going in the
correct direction
Thanks,
Jon
Thanks for the help
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Newbie needs help
Date: 15 Sep 1999 14:23:59 GMT
mike cardeiro <[EMAIL PROTECTED]> wrote:
> when i tried to download appendix a i was prompted for a
> username/password. are there any other resources that
To get the username/password, subscribe to the p1363-announce and
p1363-discuss lists (the instructions are on the web page somewhere).
One of the "Welcome to list" messages has the username and password on it.
It is an interesting password. :-)
> explain the math for us folks who have forgotten (or never
> learned) the math?
As someone's already said, RSA's Crypto Today FAQ. Also Certicom's FAQ and
white papers on elliptic curve crypto. Check for online courses and course
notes, too. Plus the sci.crypt FAQ and alt.security.pgp FAQs are good
documents to read.
-David
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: OBJECT IDENTIFIER for HMAC-SHA1-96 and HMAC-MD5-96????
Date: Wed, 15 Sep 1999 15:16:09 GMT
"Douglas Clowes" <[EMAIL PROTECTED]> wrote:
> Where does IANA keep their registered OIDs?
The authoritative list of assigned object identifiers in the
"internet" tree is available from IANA at the following URL:
<http://www.isi.edu/in-notes/iana/assignments/smi-numbers>
Object identifiers have been assigned for HMAC-MD5 and HMAC-SHA1, and
in the context of the IPSec ISAKMP framework these object identifiers
refer to the HMAC-MD5-96 and HMAC-SHA1-96 variants. I am not aware of
any specific OID assignments for HMAC-MD5-96 or HMAC-SHA1-96.
-Richard
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Wed, 15 Sep 1999 11:09:25 -0400
I don't know if this will help, but here is a little hint if you
don't know about it:
if you have a pad P, and two messages M1, M2,
the first encryption is P + M1 (where + here is XOR)
the second gives you P + M2.
If you XOR both results, you get (P + M1) + (P + M2) = M1 + M2
you get the XOR of both messages. This give you info. on your
messages.
Anton
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Wed, 15 Sep 1999 11:10:58 -0400
in your assignement, + seems to be (+ modulo 127) , not
bit XOR... so you get the result of M1 + M2 (mod 127).
------------------------------
From: Alex <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: 15 Sep 1999 11:56:28 -0400
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
I didn't believe that one-time-pads could be so vulnerable when it was
mentioned on slashdot.org recently (so much obvious nonsense gets posted
there), and posted two strings there encrypted with the same pad.
Someone posted a detailed reply describing how they broke it. You might
be able to find what you are looking for by using the search facilities
there.
Basically, you want to XOR the two messages with each other. This
cancels out the one-time-pad XOR'ing, and you end up with the same
result as if you had XOR'ed the plaintexts together. Call this string
S. Then you start XOR'ing segments of S with common words, like "the".
If the corresponding segment of one of the plaintexts was "the", then
this will cancel that out, and you will see a portion of the other
plaintext message. So if XOR'ing a segment of S with, say, "the",
results in something that looks like a portion of an English word, you
have good reason to hope that you have cracked that part of the
one-time-pad. Then you can look for words that contain that portion,
and try XOR'ing S with that, to see if you get something which looks
like English again. You keep interating this, until you've figured out
the whole message.
One thing which occurred to me after the slashdot thread about this had
died down is that this is really exploiting the strong local
dependancies that exist in English. If you do something to hide those
dependancies, would it then become significantly safer to use a
one-time-pad repeatedly? For instance, say I give you a private RSA
key, and a list of 1000 messages in English that have all been encrypted
with the corresponding public key, and then XOR'd with a one-time-pad
that I'm not going to tell you. Would my messages be safe?
Alex.
=====BEGIN PGP SIGNATURE=====
Version: PGP for Personal Privacy 5.0
Comment: Processed by Mailcrypt 3.5b6, an Emacs/PGP interface
Charset: noconv
iQA/AwUBN9/BjnzN4ZFYpUPAEQJHqACeLgf6oBTOqn2VZAxAJ6GzmAFulWcAn1v/
iNo/w/PtkjbBHxUBv1e+qakP
=pNLE
=====END PGP SIGNATURE=====
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Wed, 15 Sep 1999 16:37:51 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Tom Knight
wrote:
> I'd still say that [Stephenson] never seems to be
> trying to influence opinions. None of the characters in his books can be seen
> as heroic mouthpieces.
>
Indeed, in the preface to "Zodiac", his first published novel, he says that he
knew he was on the right track when one of his friends read the manuscript and
described the central character as "an asshole".
But then, of course, books can influence opinions even if the author does not
intend that they should...
Cheers,
Daniel.
------------------------------
From: "Dr.Gunter Abend" <[EMAIL PROTECTED]>
Subject: Re: General encryption question
Date: Wed, 15 Sep 1999 18:15:58 +0200
Andrew wrote:
>
> Is it possible to decrypt and execute a file/application
> without at any time leaving it in a decrypted state on the
> hard drive?
You may output it to a RAM disk. It needs not be very large,
you even may compress it. Beware of the swap file!
Ciao, Gunter
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Can you believe this??
Date: Wed, 15 Sep 1999 12:15:19 -0400
[EMAIL PROTECTED] wrote:
>
> Eric Lee Green wrote:
> <snip>
>
> > I will tell you right now that BCTP uses:
> > Diffie-Hellman for key exchange
> > MD5 for digest authentication
> > /dev/urandom or Ocotillo for challenge string and key generation (an
> > NT client, if one is ever done, will probably use Yarrow instead),
>
> /dev/urandom is NOT a valid source for key generation/challenge string.
> /dev/random is a good source for high quality entropy to seed a secure
> random number generator. Even the authors themselves have said that
> /dev/urandom should only be used for simple programming uses (like games and
> such).
Nonsense. They have said no such thing, because what you say is not
true.
The ONLY difference between the two generators is that /dev/random
limits the number of output bits to <= the estimated amount of
input entropy, while /dev/urandom does not. Bruce Scheier et al. have
argued (in the Yarrow paper) that this is unnecessary, given that
the PRNG is using a cryptographically strong mixing function (as
/dev/urandom does).
paul
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mystery inc. (Beale cyphers)
Date: Wed, 15 Sep 1999 14:46:36 GMT
sha99y00000 wrote:
>> > ... Communications of the ACM, January 1971, ...
> 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.
So, have *you* volunteered to create accurate on-line versions of
these documents? Very few publications have on-line versions
dating back more than a few years. It takes time and money to
accomplish that, if it wasn't planned from the start.
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Wed, 15 Sep 1999 17:05:31 GMT
Alex <[EMAIL PROTECTED]> wrote:
> I didn't believe that one-time-pads could be so vulnerable when it was
> mentioned on slashdot.org recently (so much obvious nonsense gets posted
> there), and posted two strings there encrypted with the same pad.
> Someone posted a detailed reply describing how they broke it. You might
> be able to find what you are looking for by using the search facilities
> there.
For the curious, the following is the exchange on Slashdot to which
Alex is referring. First, Alex's challenge:
> Re:Why people don't use one time pads (Score:1, Informative)
> by Anonymous Coward on Saturday August 21, @01:49PM EDT
>
> Then you have to worry about only using the pad once. If you use it twice,
> your message is totally toast. During WWII, a lot of traffic was gathered
> this way.
>
> Just twice? How?
>
> Here are two strings of numbers. I obtained them by xor'ing the ASCII of
> two English text messages with the same sequence of random numbers. What
> are the plaintexts?
>
> [171, 61, 38, 69, 203, 212, 243, 134, 223, 99, 169, 83, 117, 243, 27, 89,
> 194, 8, 227, 145, 248, 41, 131, 25, 77]
>
> [177, 58, 56, 22, 131, 216, 242, 195, 139, 98, 191, 83, 103, 242, 12, 10,
> 197, 77, 237, 155, 229, 62, 194, 13, 92, 10, 255, 249, 28, 211]
>
> Even if you can't do this, in general I take your point, though.
>
> Alex.
...and here is plambert's response:
> Re:Why people don't use one time pads (Score:5, Informative)
> by plambert on Saturday August 21, @03:44PM EDT
>
> "this is the first message"
> "now here is the second string"
>
> (i guessed at the last part, since they were of unequal length).
>
> it took me about 15 minutes to hack together some perl code to help me do
> it--easier than doing it by hand.
>
> and i've never done this before. ;-)
>
> it's amazingly simple, actually. you have two plaintexts, T1 and T2, a key,
> K, and two ciphertexts, C1 and C2. you're trying to find T1 and T2. you
> don't know (and don't really care about) K, and you know C1 and C2.
>
> so you have:
>
> C1= T1 XOR K
> C2= T2 XOR K
>
> now the problem is, we don't know K. so we think about things briefly and
> suddenly realize:
>
> C1 XOR C2 = T1 XOR T2
>
> which takes the key entirely out of things, making it simply a case of
> finding two plaintexts XORed together. which is a piece of cake (especially
> for simple plaintexts like what you provided).
>
> specifically, i took C1 XOR C2 (call it R) and went through it
> sequentially, XORing the string ' the ' (with the spaces).
>
> this gave me two hits:
> 07.......e is
> 11........... firs
>
> figuring it was likely that this string occurred in both T1 and T2, and
> unlikely that it occurred twice in any one string in such close proximity,
> i figured these were each parts of T1 and T2, respectively.
>
> then i XORed ' first ' with R in the right spot, and it gave me ' the se'.
> i tried all the letters a-z after the 'se' which formed part of a word,
> i.e. not 'sez' or 'sek' or 'sej'.
>
> with some experimentation, part of the message became clear, and it was
> easy to extrapolate to get the rest.
>
> with some effort, a program could be written to throw a dictionary at it
> (in nearly any language, and any character encoding or file format) and see
> what develops. pretty straightforward stuff.
>
> does that answer your question? ;-)
>
> --plambert
-Richard
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Ritter's paper
Date: Wed, 15 Sep 1999 14:53:40 GMT
"SCOTT19U.ZIP_GUY" wrote:
> In article <7rmpuh$6m9$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (David Wagner) wrote:
> >I hope you will believe me when I say that I intended for this to be a
> >fair comparison, where -- in both scenarios -- the cryptographers try
> >their hardest to do the best job possible with the resources available
> >to them.
> It is obvious you can't do a fair comparison becasue you lack the
> over all grasp of what cryptography is all about.
That isn't a useful contribution; you should identify at least
one significant error, which would at least lead the discussion
onward toward the truth. I assume you don't mean that the error
is DW's assumption that cryptographers would try ro do the best
job possible with the available resources, since that seems like
a plausible assumption for such an analysis.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: compression and encryption
Reply-To: [EMAIL PROTECTED]
Date: Wed, 15 Sep 1999 15:32:37 GMT
Shaun Wilde <[EMAIL PROTECTED]> wrote:
: should I compress my data before or after encryption? (binary data - with
: possibly repeated blocks i.e .exe etc)
: 1) If I compress before encyption the final data block is small.
: 2) If I compress after encryption the data block is much larger [...]
Compress before encryption (1).
: From the above I would say go for the 1st option, however I have a concern
: and it is as follows.
: If someone was trying to break the encryption all they would have to do is
: a) try a key
: b) try to decompress
: if decompression works - no errors - then the odds are on that thay have
: broken the code
: else repeat
This argument only holds if you use a compression routine with built-in
error checking. Error detection is /usually/ a positive thing, but - in
this context - it may not be.
As you say, if you /don't/ compress, there /may/ also be methods of
identify a correctly decrypted file automatically.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
May all your PUSHes be POPed.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: 15 Sep 1999 09:56:56 -0700
In article <[EMAIL PROTECTED]>,
Peter Pearson <[EMAIL PROTECTED]> wrote:
> Is NOPping out bytes easier than overwriting a file? Not if you
> came prepared. And note that by replacing a single CSP, you
> can crypto-neuter *all* the software that uses that CSP without
> having to track down the applications one by one. And note,
> further, that the various applications you want to neuter come
> in various versions each, and you'll have to track all those
> versions if you want to be sure you know where to NOP.
>
> So the burglar from *my* government agency carries a floppy disk
> with neutered copies of a few recent versions of the CSP. He locates
> your CSP, copies the appropriate version on top of it, and is
> done. What does the burglar from *your* government agency do?
My burglar comes prepared with a floppy disk containing a copy of
Anti-Fortify :-), which has a database of the the right offset to
NOP away for each version of each interesting application. No
worries about those pesky MS employees leaking our dirty laundry.
In all seriousness, yes, I agree that both approaches to "spiking"
the crypto would probably work. But why would the NSA go to the
extra effort (and extra risk of disclosure) of asking Microsoft to
add a "_NSAKEY", when it could have used other, less costly, less
risky methods? This seems to me to be the key question your
scenario should answer if it is to be a persuasive explanation.
It just doesn't seem awfully believable to me unless there's some
clear advantage to be had by using the "_NSAKEY" instead of NOPing,
and as far as I can tell, there's apparently no such clear advantage
to be had. But maybe I'm missing something. Do you disagree?
------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Wed, 15 Sep 1999 08:58:22 -0700
David Wagner wrote:
> Peter Pearson <[EMAIL PROTECTED]> wrote:
> >
> > Simple: the FBI breaks into your house and replaces your
> > Microsoft CSP with a look-alike NSA-signed CSP whose
> > random-number generator has been damaged in such a way that
> > it produces only a few billion different values.
>
> But you don't need to use the "_NSAKEY" to accomplish this; there are
> much easier ways to cripple the crypto in this scenario.
>
> (Simple technique: NOP out the call that initializes the RNG in the
> application of interest. No "_NSAKEY" needed. Ian Goldberg and I
> implemented this for Netscape several years ago, and it was a trivial
> 4-byte patch to the binary.)
Is NOPping out bytes easier than overwriting a file? Not if you
came prepared. And note that by replacing a single CSP, you
can crypto-neuter *all* the software that uses that CSP without
having to track down the applications one by one. And note,
further, that the various applications you want to neuter come
in various versions each, and you'll have to track all those
versions if you want to be sure you know where to NOP.
So the burglar from *my* government agency carries a floppy disk
with neutered copies of a few recent versions of the CSP. He locates
your CSP, copies the appropriate version on top of it, and is
done. What does the burglar from *your* government agency do?
- Peter
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Wed, 15 Sep 1999 12:14:52 -0500
Rick Braddam wrote:
> Thank you for responding. A web page I hit today posted two keys in PGP format which
>are purported to be the _key and _NSAkey. I was
> curious, so I imported them to my keyring. Funny, the keys they are signed with have
>the same fingerprint.
>
> If they ARE the Microsoft and NSA keys, it would appear that the NSA key is signed
>by Microsoft or vice-versa.
>
> If _NSAkey is a backdoor, it looks like it was left wide open. Someone was bound to
>find out about it sooner or later.
>
> Of course, everything on the page I saw could be B___S___ , anyone know who Adam at
>http://www.cypherspace.org/~adam/ is?
Anonymous posted those keys to coderpunks, Adam just put them
on his web page. What Anonymous did was to take the binary data from
the _key and _NSAKEY locations and convert them into PGP style key
data. The signature on the PGP keys is from someone else, not
MS or NSA. The purpose of generating the PGP keys was to have some
fun. Send a secret message with information that's of interest
to either NSA or Microsoft, post it publicly, and see what happens.
:-) Don't get caught!
Patience, persistence, truth,
Dr. mike
------------------------------
Date: Wed, 15 Sep 1999 12:30:58 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Ritter's paper
David Wagner wrote:
> 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.
Likewise ease of calcluation tells nothing about the quality of the definitions.
> 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].
There are several gaps here. The grlaring one is that we have no ciphers
(excluding OTP) that are secure. We have only ciphers that are not secure or
whose security we are unable to determine. Note that last: it does not mean we
"think" they are secure. It means we do not know.
This is not related to the scientific process of theorization and experiment. We
are able to theorize about degrees of security, but we are not able to conduct
repeatable experiments to confirm those theories. Thus we have theories (cipher C
is secure) that are known to be false and those whose validity is unknown.
Further, from history of cryptology, ciphers move only from the unknown class to
the known-broken class. There is no process by which we can move a cipher out of
the unknown class into the known-unbreakable category.
So the concept of probabilities or security do not apply here.
> 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.)
It appears that you are trying to create an extensible metric; one with predictive
power.
1. We cannot predict which ciphers are secure. We can only break them, not prove
them.
2. The past experience of a group of cryptographs probably isn't predictive of
their own future success at breaking ciphers much less the success of others.
> 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.
You probably need to model some kind of summation over the capabilities of
multiple opponents rather than assuming a single monolithic opponent.
> 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: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Wed, 15 Sep 1999 13:24:46 -0400
>
It is not at all surprising, a one-time-pad is just *that*, a
pad that you use *one* time. It is 100% secure in that
context, no information can be leaked. If you use it twice,
than you can get the XOR of the two messages (see my other
post), which is alot of information! Basic mathematics
proove it's security and possible misuse....
Anton
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Mathematical models and encryption
Date: Wed, 15 Sep 1999 13:31:36 -0400
>
I don't exactly understand your question, but here is a try to
an answer.
An encryption algorithm is formaly defined by a 5-tuple
(P,C,K,E,D), where P is the set of plaintexts, C the set
of cipherd texts, K the set of keys, E the set of encryption
algorithms and D the set of decryption algorithms.
The key in use, k, defines the function e_k in E that is
to be used, same for d_k (for asymetric, you use different
k for encryption/decryption). e_k and d_k share the
property that d_k(e_k(x)) = x for x in P.
If that is what you mean by a model, well there you go.
anton
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Ritter's paper
Date: Wed, 15 Sep 1999 16:29:25 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>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.
My position on these issues does not make exciting reading, as it
consists of sitting resolutely on the fence. While I don't feel I have
the credentials to have an opinion piece from me published in a major
publication, I have now taken some space on my web page to address
these issues, in response to this suggestion, at:
http://www.ecn.ab.ca/~jsavard/mi0609.htm
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Alex <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: 15 Sep 1999 13:46:30 -0400
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
> It is not at all surprising, a one-time-pad is just *that*, a pad that
> you use *one* time. It is 100% secure in that context, no information
> can be leaked. If you use it twice, than you can get the XOR of the
> two messages
Yes, shame on me for not thinking of that myself.
Alex.
=====BEGIN PGP SIGNATURE=====
Version: PGP for Personal Privacy 5.0
Comment: Processed by Mailcrypt 3.5b6, an Emacs/PGP interface
Charset: noconv
iQA/AwUBN9/bU3zN4ZFYpUPAEQJz6ACfYi8GjP5sKkBe870v5s4wYF0EAB8AoIEM
8rDGx/D6ZtlI8NDpgH52u06T
=TMjK
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
