Cryptography-Digest Digest #953, Volume #8 Sat, 23 Jan 99 07:13:05 EST
Contents:
Please help. Need protocol advice. ([EMAIL PROTECTED])
Re: Edupage coverage of Flannery story ([EMAIL PROTECTED])
Re: a^x mod n question (Matthew Skala)
Re: Please help. Need protocol advice. ("Else")
Re: Who will win in AES contest ?? (Markus Kuhn)
Re: Metaphysics Of Randomness ("R H Braddam")
Re: Metaphysics Of Randomness (R. Knauer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Please help. Need protocol advice.
Date: Sat, 23 Jan 1999 08:40:55 GMT
I'm looking for a possible way to secure two-way (client/server)
communication even against attacks that may reverse-engineer and subvrt the
code on one end. I didn't think that it was fully possible, but in
sci.crypto."Re: Trying to find simple, yet effective crypto..." by Mr. Tines,
it is implied that there is such an animal. My problem is, taken some (but
preferably all) of the specifications of a worst-case scenario can
communication remain secure somehow ... I'll take any and all feasible
protcols and/or algorithms, even if they're only theoretical and possibly
impractical? Worst-case is defined as so: 1) The "enemy" is a large,
well-funded body ... say the United States's NSA; 2) the client program WILL
be reverse-engineered; 3) the host will NOT recognize that the client has
been compromised; 4) the client routinely NEEDS sensitive information; 5)
the network is slow ... assume 2400 baud modem or something archaic.
My deepest most heart-felt thanks go out to anyone that holds the answer.
I've been reading Schneier's exemplary book and racking my brains trying to
come up with something, but my current solution is far from perfect. Once
again, tahnks in advance for ANY insight into this problem.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Edupage coverage of Flannery story
Date: Sat, 23 Jan 1999 07:21:08 GMT
A shame Ms. Flannery is blissfully ignorant or incapable of publishing her
algorithm on the Internet.
In article <78357t$b6g$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Matthew Skala) wrote:
> (Clipped from a longer publication - I hope I'm not breaking their
> distribution terms by reposting it)
>
> >************************************************************
> >Edupage, 14 January 1999. Edupage, a summary of news about information
> >technology, is provided three times a week as a service of EDUCAUSE,
> >an international nonprofit association dedicated to transforming higher
> >education through information technologies.
> >************************************************************
>
> >IRISH GIRL CREATES CODE TO IMPROVE E-MAIL SPEED BY FACTOR OF TEN
> >Sixteen-year-old Irish schoolgirl Sarah Flannery has devised a new code
> >that will send e-mail ten times faster, and just as securely, as the
> >current data protection code for e-mail. The current code was developed in
> >1977 by three MIT students. Flannery says she is considering publishing her
> >discovery rather than patenting it, because she does not want people to
> >have to pay for it. She is being deluged with job and scholarship offers.
> >(The Times Of London 13 Jan 99)
>
> >Edupage is written by John Gehl ([EMAIL PROTECTED]) and Suzanne Douglas
> >([EMAIL PROTECTED]). Telephone: 770-590-1017 Edupage readers may be
> >interested in taking a look at their article in this month's issue of
> >"World& I" magazine: http://www.worldandi.com
>
> >Technical support for distributing Edupage is provided by Information
> >Technology Services at the University of North Carolina at Chapel Hill.
>
> (end of quote)
>
> It's a surprise to hear that Rivest, Shamir, and Adleman were "students"
> when they created RSA... I was pretty sure they were all professors, and
> not all at MIT, in 1977. Is that my error, the Times's, or Edupage's?
> --
> The third girl had an upside-down penguin on Matthew Skala
> her stomach, so the doctor told her, "I'll Ansuz BBS
> examine you for free, if you and your (250) 472-3169
> boyfriend will debug my Web server." http://www.islandnet.com/~mskala/
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: a^x mod n question
Date: 22 Jan 1999 22:48:42 -0800
In article
<[EMAIL PROTECTED]>,
Rx Video <[EMAIL PROTECTED]> wrote:
>a^x mod n=((a mod n)^x) mod n - calculate a mod n first, and then raise
>it to power x and calculate modulo from this result. It gives the same
>result.
>There are probably some good reasons for doing things the way
>B.Schneider described, still, I would like to know why is it that way.
You seem to want to just skip over the modulo reductions in the intermediate
steps, and do them all as one reduction at the start and one at the end.
That's perfectly feasible mathematically. You don't even actually have to
do the one at the start, you can just calculate a^x and reduce it once at
the end. The only problem is that x is often a big number - big enough that
there isn't enough RAM in the world to hold a^x. Remember that the
*length* of a^x is roughly the *length* of a times the *value* of x. And
x is often more than a googol. A googol is a lot of bits to be pushing
around. You have to do some modulo reductions earlier in the process or
else you run out of space. Also note that as the numbers get bigger the
work gets slower, so a reduction will often pay for itself in saved time
for subsequent multiplications - you're not usually winning by reducing
the number of modulo reductions you do.
By the way, the author you're referring to spells his name "Schneier" - no D.
--
The third girl had an upside-down penguin on Matthew Skala
her stomach, so the doctor told her, "I'll Ansuz BBS
examine you for free, if you and your (250) 472-3169
boyfriend will debug my Web server." http://www.islandnet.com/~mskala/
------------------------------
From: "Else" <[EMAIL PROTECTED]>
Subject: Re: Please help. Need protocol advice.
Date: Sat, 23 Jan 1999 13:58:55 +0300
Here is how I solved very similar problem:
1. I got RSAEURO package (if you are in the US, you would need RSAREF2) and
compiled it into the server. You have to resolve the legal issues for
yourself.
2. When the server starts it generates a 1024 bit RSA keypair.
3. Every client fetches the public key from the server.
4. Using the fetched public key of the server, client encrypts a 128 bit
random block and passes it back to the server. The random block is generated
by the client - pay attention to the source of randomness.
5. Server decrypts the block using the private key.
6. All following client-server communication is encrypted by RC4 using the
128 bit block as the RC4 key.
7. A new RSA keypair is generated by the server every 24 hours.
This scheme is approximately (except for 7) equivalent to SSL.
[EMAIL PROTECTED] wrote in message
<78c1un$jbn$[EMAIL PROTECTED]>...
>I'm looking for a possible way to secure two-way (client/server)
>communication even against attacks that may reverse-engineer and subvrt the
>code on one end. I didn't think that it was fully possible, but in
>sci.crypto."Re: Trying to find simple, yet effective crypto..." by Mr.
Tines,
>it is implied that there is such an animal. My problem is, taken some (but
>preferably all) of the specifications of a worst-case scenario can
>communication remain secure somehow ... I'll take any and all feasible
>protcols and/or algorithms, even if they're only theoretical and possibly
>impractical? Worst-case is defined as so: 1) The "enemy" is a large,
>well-funded body ... say the United States's NSA; 2) the client program
WILL
>be reverse-engineered; 3) the host will NOT recognize that the client has
>been compromised; 4) the client routinely NEEDS sensitive information; 5)
>the network is slow ... assume 2400 baud modem or something archaic.
>
>My deepest most heart-felt thanks go out to anyone that holds the answer.
>I've been reading Schneier's exemplary book and racking my brains trying to
>come up with something, but my current solution is far from perfect. Once
>again, tahnks in advance for ANY insight into this problem.
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Markus Kuhn)
Subject: Re: Who will win in AES contest ??
Date: 23 Jan 1999 11:06:20 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Piotr Kulinski)
writes:
|> What do you think who will win in AES contest ???
I think both a 16-round version of Serpent and Twofish are
clearly the two top candidates at the moment.
The Serpent authors overdid the paranoia versus efficiency
tradeoff a bit too much towards paranoia when they originally
specified 32 rounds, but this parameter is most easily changed
and when the number of rounds is standardized in all algorithms
for comparable protection against linear and differential
attacks, then it seems that Serpent and Twofish are best performing.
Serpent uses mechanisms that are extremely well understood by
years of work on DES, therefore it is quite easy to feel very
comfortable about it after a relatively short evaluation period.
It seems Mars is not really implementable in smartcard chips
(typically 128 bytes of RAM), and RC6 is based on the very little
understood technique of data-dependent rotations, which makes the
more conservative cryptanalysts a bit sceptical, given the
short evaluation period.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
------------------------------
From: "R H Braddam" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Sat, 23 Jan 1999 05:15:30 -0600
It's frustrating to read posts from people with
opposing views, when they both make sense. I have some
questions (below), maybe someone can help me understand
this.
Patrick Juola wrote in message
<78ab5s$q1f$[EMAIL PROTECTED]>...
>In article <[EMAIL PROTECTED]>,
>Dorina Lanza <[EMAIL PROTECTED]> wrote:
>>Patrick Juola wrote:
>>
>>> In article <[EMAIL PROTECTED]>,
>>> Dorina Lanza <[EMAIL PROTECTED]> wrote:
>>> >> > You are making the mistake of trying to
characterize a number as
>>> >> > random on the basis of some inherent property,
like lack of
>>> >> > correlation or bias or somesuch. But we know
that a characterization
>>> >> > like that will not properly characterize
crypto-grade random numbers.
>>> >> > Only the characterization of the generation
process is proper.
>>> >>
>>> >> Holy Cow Bob, if I give you a certifiably random
string (say, with a
>>> >> gorgeous Allan Deviation plot) and present it to
you as crypto-grade, and
>>> >> you give me one of your crypto-grade strings,
I'll be able to test and
>>> >> certify that your crypto-grade string is random,
but you have no way of
>>> >> knowing that I fibbed to you about the string I
gave you because there is
>>> >> no test to distinguish between crypto-grade
strings and random strings. We
>>> >> have discovered a distinction without a
difference!
I guess this identifies the first question. What
characterizes a random number as suitable for
cryptographic use? Is there a different set of
requirements for random numbers used for the OTP and
(collectively) session, public, or private keys? I
understand that the length of the key for the OTP is
the same as the message length, and that keys for
session keys, private keys, and public keys are not. Is
there any other difference?
>>> >I think it's worse than this. The statement that
the output of a filtered
>>> >random source is non-random is false. If, for
crypto purposes, we exclude
>>> >pathological values such as zero from a TRNG we
still have an equiprobable
>>> >selection from a pool of possible values. The
fact that the pool is slightly
>>> >smaller does not reduce the randomness because the
selection process is the
>>> >same. The entropy would be slightly less, but not
the independence of the
>>> >samples.
>>>
>>> "The entropy would be slightly less" is sufficient
to make the
>>> resulting system less than perfectly secure. At
this point it's
>>> just Yet Another stream cypher.
This brings up another set of questions.
First, do you use ALL the output of a TRNG? If not,
how do you select which part of the output to use? Does
your selection affect the "randomness" of the remaining
output? If so, how, since each bit output is completely
independent of all preceding bits?
Second, do you accumulate TRNG output for later use? Or
do you just use that portion of output which is
generated while you are encrypting a message or data? I
understand that accumulating the key introduces risks,
but you have to distribute keys anyway.
>>False. A filtered pad is not less secure than an
unfiltered pad. (Now, before we
>>spin lock on yes/no/yes/no..., please give a summary
of your reasons for
>>concluding the filtering weakens an OTP.
>
>Simple statistics. If you filter the pad -- and I
know that (and how)
>you filter the pad, which is a standard and defensible
assumption --
>then I can eliminate potential decryptions.
>
>A simple example : if I know that your two possible
messages are
>"attack at noon" and "attack at dawn", and I receive a
cyphertest message
>reading "attack at noon", I cannot, in fact, infer
that you intend to
>attack at noon *OR* at dawn.
>
How do I determine that those are the only two possible
messages? I thought that the ciphertext would decipher
to all possible plaintexts using an OTP.
>If I know that you throw away all pads that are all
zero, and I receive
>the message above, I know that you do *NOT* intend to
attack at noon,
>I therefore know that you will attack at dawn.
>
>q.e.d.
>
>Unlikely? Yes -- but no more unlikely than the all
zero pad being
>generated in the first place.
What is the actual likelihood of a readable text string
being output from an OTP? Most of the encrypted files
I've looked at contained very few readable strings of
even two characters. I would think that a readable
string output would be more likely to be the result of
an accidental transmission of plaintext or a zero key
than it would be the result of a readable string
encrypting to another readable string.
>(n.b. -- if the message I receive reads "attacd at
nown", and you use
>a stronger filter of never allowing six successive
zeros, then I can
>still unbutton your message. The reason being the pad
necessary to
>produce "attack at noon" would be an illegal pad --
and hence you're
>still attacking at dawn).
Is this an indication of a "fatal flaw" in the OTP?
>From what I've read in this newsgroup, it appears that
much of an analyst's work is discovering how plaintext
is leaked into the ciphertext. With the OTP, any byte
of zero in the key leaks a plaintext character, and
that would seem to make analysis possible. Or, as
described here, maybe easy. On the other hand, if I
knew that the only two possible messages were "attack
at noon" and "attack at dawn", I wouldn't bother
worrying about which the message specified. I'd already
know enough to prepare for an attack.
>>My reasons for concluding the opposite are contained
in this
>>gedanken experiment. [snip]
>
>Math generally trumps gedanken experiments. Math
*plus* examples generally
>trumps even math. 8-)
>
>>
>>> As to whether or not the loss of entropy is
significant to make a
>>> practical difference -- that depends on the degree
of filtering.
>>> What you do really buy by doing the filtering? Not
much --- and
>>> every time the filter triggers introduces a
weakness.
>>
>>Among other things, a crypto system needs to inhibit
the identity operation on
>>plaintext. I.e., the idea of a crypto system that
includes the possibility that
>>ciphertext == plaintext has a flaw. Mathematically,
the system including the
>>possibility is infinitesimally "stronger" due to the
larger search space, but
>>that's not the unit of measure for crypto strength.
See what I mean? Both paragraphs above make sense and
sound right. There are (simplistically) only four
possibilities:
The first is wrong and the second is right.
The first is right and the second is wrong.
Both are right.
Both are wrong.
However, if both are right, then both are also wrong,
if they actually contradict each other.
Maybe they don't contradict each other and both are
right.
I mean, theoretically, a TRNG could start up generating
a 2^1000 bit sequence of zeros, and that be a
legitimate output. I don't think that would be very
useful. Same with a sequence of ones the same length.
Either could be a valid output, though, if I understand
what I've read here ( in sci.crypt) correctly. I guess
valid doesn't have to mean useful. I guess I could just
throw the TRNG away and get another, after a period of
monitoring to see if the sequence changes into one more
useful.
The TRNG could also start up generating a random
sequence of ones and zeros, which should be more likely
and definitely would be more useful. Suppose it ran
long enough to generate 3,000,000 bytes before I needed
to use it, and they were 1,000,000 bytes of mixed ones
and zeros, 1,000,000 bytes of zeros, then 1,000,000
bytes of mixed ones and zeros. Does the fact that I
didn't use the 3MB of output affect the entropy or
randomness of the 3,000,001 through 3,000,016 bytes I
use for a Blowfish session key? I don't think so, but
not for mathematical reasons. Just because the TRNG
doesn't know if I use its output or not. My use or lack
of it has no effect on the output. Every bit will
continue to be generated completely independently of
every preceding bit. Does my lack of use of output
(between messages) constitute an unintentional form of
filtering?
>This is simply and utterly false. This is, in fact,
one of the major
>weaknesses in the Enigma system. By inhibiting the
identity operation,
>one made it very much easier to evaluate and discard
wrong or unlikely
>decryptions.
>
> -kitten
I've been writing about a type of use practically
impossible with the OTP. I was ignoring the pad
distribution problem and the necessity of generating
pads ahead of time and distributing them before
communications took place. I think my comments about
use of the TRNG are still valid, even though they
require distributing the pad after the message was
sent. That isn't practical, but it is possible. My use
of a TRNG would be to generate session, public, and
private keys. The concerns about filtering are
applicable there, too.
Thanks in advance for any clarification or corrections
you provide.
Rick [EMAIL PROTECTED]
Murphy's Law is the only sure thing in the universe.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Sat, 23 Jan 1999 12:03:06 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 22 Jan 1999 19:20:44 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> If a secure OTP could be generated from the XOR of two text streams,
>> who needs a TRNG?
>Sure. That's a valid criticism of the letter-from-Aunt-Jane kind of camoflage, but
>only if you start with a given letter from Aunt Jane. If you're willing accept *any*
>letter than looks like it came from Aunt Jane then you aren't mixing two text streams.
I don't understand what you just said. If the Aunt Jane letter is
composed of intelligible text then using it to create the key has
nothing to do with whether it is from a particular letter or any
letter.
Please elaborate, in case I missed something here.
Bob Knauer
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
--Justice Robert H. Jackson
------------------------------
** 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
******************************
