Cryptography-Digest Digest #938, Volume #10 Thu, 20 Jan 00 15:13:01 EST
Contents:
Re: Forward secrecy for public key encryption: MYH (lcs Mixmaster Remailer)
Re: Beginners questions re-OTPs ("Trevor Jackson, III")
Re: Predicting Graphs. ("Trevor Jackson, III")
free-file encryption (None)
Re: Wagner et Al. ("Trevor Jackson, III")
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Combination of stream and block encryption techniques (wtshaw)
Re: SRP optimisation (Paul Crowley)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: Help -Perl encryption (Paul Crowley)
Re: McDonald's claims Nobel peace fries [off-topic] (Guy Macon)
Re: Wagner et Al. ("Trevor Jackson, III")
----------------------------------------------------------------------------
Date: 20 Jan 2000 19:20:07 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Forward secrecy for public key encryption: MYH
David Hopwood writes:
> 1. Choose distinct random primes p_1..p_r, of roughly equal size
> and where the factorisations of p_i - 1 are known, such that
> the values (p_i - 1)/2 are odd and pairwise relatively prime,
> and q_i is a prime dividing (p_i - 1)/2 for each i.
A toy example shows that the construction doesn't work.
Let p_1 = 23, q_1 = 11.
Let p_2 = 31, q_2 = 3.
> Let m = product[p_i: i = 1..r]
> q = product[q_i: i = 1..r]
> z_i = (p_i - 1)/q_i
> s = sum[z_i: i = 1..r]
m = 713
q = 33
z_1 = 2
z_2 = 10
s = 12
> 2. Select elements alpha_i that generate subgroups of sizes q_i, as
> follows:
>
> a) Choose an element g of Z*_m that is primitive in each of the
> prime fields Z_{p_i}, i.e., such that for i = 1..r, p_i - 1
> is the smallest exponent for which g^(p_i - 1) = 1 (mod p_i).
>
> (To test whether g is primitive in Z_{p_i}, check that
> g^((p_i - 1)/a) mod p_i != 1 for each prime factor a of
> p_i - 1.)
The value g = 11 works.
For p_1, we test that none of 11^2 or 11^11 = 1 mod 23.
For p_2, we test that none of 11^2, 11^3, 11^5, 11^6, 11^10, or 11^15 = 1
mod 31.
> b) Compute alpha_i = g^z_i for i = 1..r.
> alpha = product[alpha_i: i = 1..r].
It is not clear whether the first line is to be taken mod m or mod p_i.
Assuming mod m, we get:
alpha_1 = 11^2 mod 713 = 121
alpha_2 = 11^10 mod 713 = 439
alpha = 121 * 439 mod 713 = 357
> [Note that:
> - g has maximal order phi(m) in Z*_m,
It does not. phi(m) = (p_1-1)(p_2-1) = 660, but 11^330 mod 713 = 1.
> - alpha_i has order q_i,
It does not, at least if taken mod m.
alpha_1 ^ q_1 mod m = 121 ^ 11 mod 713 = 576
alpha_2 ^ q_2 mod m = 439 ^ 3 mod 713 = 652
> - alpha has order lcm[q_i: i = 1..r] = product[q_i: i = 1..r] = q,
It does not:
alpha^1 mod m = 357 ^ 33 mod 713 = 438.
A goal of the construction was to get alpha to have order q, but it fails.
The same thing happens if we take the exponentiation in step (2b) above to
be mod p_i, for then alpha_1 = 6, alpha_2 = 5, and alpha = 30, which also
does not have order 33, mod 713.
------------------------------
Date: Thu, 20 Jan 2000 14:28:13 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Beginners questions re-OTPs
Bill wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(John Savard) wrote:
> >On Wed, 19 Jan 2000 12:11:25 GMT, [EMAIL PROTECTED] (Bill) wrote, in
> >part:
> >
> >>I'm a total beginner and am interested in learning how to attack OTP's.
> >>From what I have found on the net and Mr. Schneier's book there are three(?)
> >>ways of attacking OTP's:
> >>1. The method used to generate OTPs.
> >>2. Statistical analysis of the cyphertext.
> >>3. Brute force.
> >
> >If methods 1 or 2 work, it isn't an OTP. Method 3 cannot work, since
> >"brute force" applied to an OTP key yields all possible messages of
> >the length of the one intercepted.
> >
> >John Savard (teneerf <-)
> >http://www.ecn.ab.ca/~jsavard/index.html
>
> I agree if methods 1 & 2 work then it isn't a "true" OTP but my question was
> what are methods 1 & 2.
> I'll rephrase the question, If you have message(s) that were encrypted with a
> "supposed" OTP what methodology/statistical analysis would be carried out to
> try and break it?
> All I can find on the net are debates about what a "true" OTP is and what
> it isn't and what "randomness" really means. I can find no explanations of how
> to go about breaking a "supposed" OTP.
> For just about every other form of encryption, both "classical" and modern,
> there are detailed descriptions on how to start attacking them.
> (e.g. for the Vigenere cipher programs to break it and for modern
> mathematically based encryption the method, among others, of "differential
> cryptanalysis". )
>
> Sorry if this is a silly question but as I said I am a newbie.
The reason there are well-defined attacks upon other kinds of ciphers is that those
ciphers have a
particular structure that can be analyzed. An OTP key stream can come from just about
anywhere, so there
is no predefined structure to analyze. The most general form of attack is to figure
out where the keys
are coming from and try to predict/duplicate them. THis usually requires massive
amounts of data,
including plaintext. From the plain and cipher texts you can calculate the keys.
Once you have the keys
you can look for patterns. If there's a lot of qwerty & asdfgh someone is pounding a
keyboard and you
look for that kind of bias. If a key reads like Shakespeare or Omar Khayyam you start
trying classical
literature. If the key looks like a a WAV file you find out what kind of music it is.
If the key looks
like a pin up girl you try to find the photographer. If the key looks like a PRNG you
try to find the
structure and seed.
You can also check for repeated keys. The re-use of OTP keys contradicts the term ONE
TIME Pad, but it
does happen. All Pseudo-OTPs have this flaw.
Once you characterize the key generator you perform the same kind of analysis that you
would on a block or
stream cipher, because you know something about how it works. As your analysis
progresses you will gain
the power to predict the keys. When you can predict them reliably you've solved the
cipher system (not
the cipher, the system).
There was a pretty massive project called Venona that had some success using this kind
of analysis. Much
of their success was due to the re-use of keys, but studying their process will give
you a good grounding
in the topic.
------------------------------
Date: Thu, 20 Jan 2000 14:29:27 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Predicting Graphs.
[EMAIL PROTECTED] wrote:
> Come on, somebody, answer my question!
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
The answer to your question is No.
------------------------------
From: None <[EMAIL PROTECTED]>
Subject: free-file encryption
Date: Thu, 20 Jan 2000 11:22:24 -0800
Free file encryption!
Ability to upgrade into your programs!
No royalties!
http://www.aasp.net/~speechfb
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: Thu, 20 Jan 2000 14:49:27 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Shawn Willden wrote:
> Guy Macon wrote:
>
> > A normal NT installation does not give
> > ordinary users debugging rights. or access to certain portions of the
> > disk (and you can add your crypto directory to the portions that
> > ordinary users cannot access).
>
> Can an NT installation be set up such that some files are not accessible even to the
> Administrator? For an system I'm building, I'm seriously considering locking out the
> Administrator account.
>
> Shawn.
It is not possible to prevent an administrator who wants to gain access from gaining
access. You can require the administrator to perform an audit able action (take
ownership) in order to gain access.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 20 Jan 2000 14:47:46 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>
>On 20 Jan 2000 05:16:43 GMT, in <8665nr$6ro$[EMAIL PROTECTED]>, in
>sci.crypt [EMAIL PROTECTED] (Michael Kagalenko) wrote:
>
>>Paul Koning ([EMAIL PROTECTED]) wrote
>>
>>]Crystals? Not likely. Resistors, noise diodes, Zener diodes, all
>>]those sound plausible, but crystals won't serve at all for this
>>]application.
>>
>> Yes, they will. Crystals have thermal noise.
>
>OK, so just how much thermal noise would one measure from a crystal,
Not much. Lots of signal, not much noise, but it is there.
>how would we measure it
The best way would be to ufe a standard Jitter test set. Anyone who
designs CD players has one.
>and where can we find a published reference to back that up?
Any databook from any crystal manufacturer.
>At one time, crystal filters were used in fine communications
>receivers; such receivers are intimately involved with noise, and are
>compared in part by actual noise measurement. We can thus reasonably
>conclude that in communications receivers any noise which was added by
>a crystal filter was far below the modest signal levels involved.
Crystal filters are narrowband bandpass filters. Thet do add a bit of
noise (not much) in band but it's worth it to reject noise and signal
from out of band. (You use a crystal oscillator for a RNG, not a crystal
filter)
Despite the low noise/high signal, a crystal oclillator makes
a fairly good RNG that is very easy to interface to a PC.
Send the TTL level output to an input line on your parallel
port, wait long enough between measurements to make whether
the signal is high or low random if the jitter is random,
then run it through a Von Neuman compensator. This has an
advantages over resistor noise in that it is less vulnerable
to outside electrical interference. The data rate is slow.
What I can't decide is whether I prefer ceramic oscillators
instead of crystal oscillators for this application.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Combination of stream and block encryption techniques
Date: Thu, 20 Jan 2000 14:09:10 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> The point worthy to be repeated is that one need not keep a strict
> distinction between stream and block ciphers, i.e. there is no sharp
> boundary between these, and one can therefore do one's design from
> a more 'unified' (hence rational) standpoint, making use of the
> repertoire of techniques/experiences accumulated in the two
> hithertofore more or less separated subfields of cryptology. I am
> glad too to see that this viewpoint has now received clear support
> from the 'establishment'.
>
This is nnot a new view, butone that I have forwarded for some times. It
just seems that Bro. Bruce is just a hepit slow to adopt it publically.
Trying to find the establishment in such a field that is so dynamic on
*ours* is generally apt to have negative inpact on new ideas rather than
to be helpful. Please do not try to find the status quo, as some would
have that fixed in a egocentric view of reality rather than feeding new
enthusiasms to expand the field. Cryptography is such a field that logic
is your only required authority, as it in for those of whom you might
choose to worship. Beware of capitalizations of prejudice.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: SRP optimisation
Date: 20 Jan 2000 18:49:20 -0000
Keith Burdis <[EMAIL PROTECTED]> writes:
>
> >> Does having the server send its evidence first adversely affect the
> >> security of SRP in any way?
>
> > Now the adversary can do an off-line password guessing attack.
> You are quite correct. I've included a full description of the details of
> the attack below.
Thanks - this was enlightening! I'll add my own thoughts here:
This isn't an incidental property of the way the verifiers are
calculated, AFAICT, but an essential one. With SRP, an attacker can
get two kinds of data: snooped sessions, where it doesn't know either
ephemeral private key, and attacker-initiated sessions, where it knows
one of them. Snooped sessions are essentially a mystery to it because
all the unknowns are too high-entropy to attack. But with sessions it
initiates itself, the only important unknown is the password itself.
Now the thing that makes server verification work in SRP is that it
proves it has the verifier corresponding to your password, so it will
only work if given the correct password.
Thus if the server provides information sufficient to verify itself
before it's verified the client, a password attack can be mounted; but
it's safe to provide it once the client is verified because that means
the holder of the ephemeral private key "a" has the password.
I'm sure you already knew this, but I didn't, so I'm glad to have been
given occasion to think about it!
Unfortunately, it seems you *can* mount a password-guessing attack if
you can fool a client into thinking you're the server. That's quite a
bit harder, though.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 20 Jan 2000 19:04:55 -0000
"r.e.s." <[EMAIL PROTECTED]> writes:
> Yes, 52! <<< 256!, but 52! is also the size of the state-space for
> the Solitaire algorithm. Is there any reason to believe that the
> ARC4 stream generator, extended to M=52, would be of worse quality
> than Solitaire? (Of course, both might be badly flawed.)
Solitaire is certainly biased, see
http://www.hedonism.demon.co.uk/paul/solitaire/
> I would like to know more about any bias in RC4. Are there references on
> the web?
http://www.hedonism.demon.co.uk/paul/rc4/ - I recently found out that
there's also a paper by Jovan Golic on bias in the least significant
bits.
> Concerning your second point, I find the method that I decribed above
> (using 54 cards) to be roughly comparable to Solitaire in speed.
OK. I'm surprised! Have you checked your results against a computer
implementation of your cipher?
I'll try and measure the bias in RC4-54 when I get time.
> A side question is what is the state space size for Solitaire. It seems
> to me that, just as my card-deck implementation of ARC4 uses the jokers
> as pointers, so does Solitaire, although in a more complicated way.
Solitaire's state space is slightly larger than that of your cipher:
54! compared to 52! * 52 * 52. That's because with your cipher jokers
can't end up on the bottom, and the order of two jokers next to each
other can't matter.
> (Note that arriving at a joker in the final step of Solitaire is a "null"
> result, consistent with them being pointers and not part of the state
> vector itself.)
They are part of the state vector. They just get skipped in the
keystream generation stage.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 20 Jan 2000 19:10:05 -0000
CLSV <[EMAIL PROTECTED]> writes:
> Well you could skip the key setup phase completely at the
> expense of communicating the initial 52-card state of
> the deck as your secret key. If you do 10 proper shuffles
> the order of the cards will be random enough.
If you have a channel over which you can communicate such a key, why
not send the message over it? Or use one-time-pads?
The convenient thing about Mirdek is that you and I can meet up one
day and agree a nice, memorable passphrase, then much later you can go
and buy a pack of cards, encrypt as many messages as you like, and I
can decrypt them all.
> Well, I've tried it (not for speed I must admit) and
> I believe calculating modulo 52 is possible for most people.
I'd be interested to hear some stopwatch results for this one.
> One thing I would like to see in MIRDEK is a richer character
> set. "A".."Z", "0".."9", " ", and "." would me enough.
This is pretty much impossible. If you use the jokers you could
create a cipher with one extra character, perhaps " "; I suggest a
number encoding on the Web pages, and you can use STOP telegram-like
for full stops (though of course it takes 2:30 to encode it). But
then what will you map to joker in the output? No, I think I'll keep
it the way it is. Mirdek depends fundamentally on having twice as
many cards as characters.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Help -Perl encryption
Date: 20 Jan 2000 19:20:19 -0000
"Andor Bariska" <[EMAIL PROTECTED]> writes:
> Why not try Bruce Schneier's Solitaire algorithm, you'll find the PERL
> script
> and documentation on Counterane's site
> (http://www.counterpane.com/solitaire.html).
Solitaire is intended *only* for situations where one or both of
encryption and decryption must be done by hand, without the aid of a
computer.
There are modules for Perl that do Blowfish encryption and others that
talk to OpenSSL for a huge number of crypto primitives, or there's my
ludicrously small implementation of RC4 available from my Web pages...
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: McDonald's claims Nobel peace fries [off-topic]
Date: 20 Jan 2000 14:55:20 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David Hopwood)
wrote:
>
>Guy Macon wrote:
>> New research in America has uncovered a previously unrecognised
>> fact of diplomacy: no country with a McDonald's has ever gone to
>> war with another.
>
>Counterexamples:
> - UK against Argentina.
> - Western countries against Iraq,
> - NATO countries against Serbia,
> - Russia against Chechnya.
I would be more impressed with your counterexamples if there had
actually been a McDonald's in both countries at the time of the
war. I realize that the part you quoted (not my words but those
of the news report) are unclear as to whether "another" means
"another country" or "another country with a McDonald's", but the
rest of the article makes the latter meaning clear and even
points out that the first McDonald's in Argentina went up after
the falklands war with the UK.
------------------------------
Date: Thu, 20 Jan 2000 15:10:54 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > Can an NT installation be set up such that some files are not accessible even to
>the
> > Administrator? For an system I'm building, I'm seriously considering locking out
>the
> > Administrator account.
>
> IIRC, no. When a user requests access to a secured object, the first
> security check the system does is to find whether the user has the
> ability to take ownership of the object. If they do, the user is
> immediately granted access without any other checks being done.
Do you have a reference for this? Under NT v4 sp3-5 removing both local and domain
administrator from a file system ACL prohibits access. Note that many resources have
default access privileges for OWNER/CREATOR and Administrator. The latter would be
superfluous if access were automatically granted.
------------------------------
** 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
******************************
