Cryptography-Digest Digest #561, Volume #9 Tue, 18 May 99 18:13:02 EDT
Contents:
Re: prime numbers and the multplicative inverse ([EMAIL PROTECTED])
Re: Can Somebody Verify My DES execution? (wtshaw)
Re: symmetric boolean functions (Medical Electronics Lab)
Re: breaking xor encryption? (Frank Gifford)
Re: Musing on and Factoring of a (special) 782-bit Modulus
([EMAIL PROTECTED])
ALF'S PRIVACY MAIL DROP (ALF)
Testing my encryption code (Cory C. Albrecht)
Re: ciphersaber-2 implementation help? ([EMAIL PROTECTED])
How to understand/program more advanced crypt. (Mika Stenberg)
Re: prime numbers and the multplicative inverse (John Savard)
Re: prime numbers and the multplicative inverse (John Savard)
Re: Can Somebody Verify My DES execution? (Thomas Pornin)
Re: prime numbers and the multplicative inverse (Chris Monico)
Re: prime numbers and the multplicative inverse (Chris Monico)
Re: where can i find a frequency list? (RREYNARD)
Re: How to understand/program more advanced crypt. ("Steven Alexander")
Re: Need to design basic authentication system ("Tim Mavers")
Re: True Randomness & The Law Of Large Numbers ([EMAIL PROTECTED])
Quadibloc III errors corrected (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: prime numbers and the multplicative inverse
Date: Tue, 18 May 1999 16:09:47 GMT
<snip>
It's ok the question was answered in private.
Tom
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Can Somebody Verify My DES execution?
Date: Tue, 18 May 1999 12:23:49 -0600
In article <7hrk7q$8do$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Thomas Pornin) wrote:
>
> key : 01234567 89abcdef
> plain : 01234567 89abcde7
> cipher : c9574425 6a5ed31d
>
Having written dozens of different encryption programs, I know that more
comprehensive evaluation is needed.
Depending on the nature of a mistake, it can affect the results to
different degrees, even being obscure enough only to occur most
infrequently. Now, this can really drive you up the wall when it
occurs. Similiarly, finding a solution to such a bug is most rewarding.
Perhaps I've been lucky, many applications have straight forward mistakes
that you correct as you iron out the sourcecode. Sometimes their are
seemingly insolvable ones that you need to deal with. The best tactic is
to put the thing away until your brain clears of it so that you can take a
fresh start. In time, any acknowledged error can be conquered, but you
have to make it come up before you can fix it.
For DES or any other ready algorithm, the necessity is to exercise your
version and comparative with the results of another's implementation as
much as possible.
For a new algorithm, I like to compare intermediate results between
encryption and decryption processes.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Crossposted-To:
sci.chem,sci.econ,sci.image.processing,sci.electronics.design,sci.physics,sci.physics.fluid-dynamics,sci.math
Subject: Re: symmetric boolean functions
Date: Tue, 18 May 1999 12:56:56 -0500
Hankel O'Fung wrote:
> Does anybody know what are the applications of symmetric
> boolean functions and shift-invariant boolean functions of
> n (>=3) boolean variables?
>
> Here, a function f: {0,1}^n --> {0,1} or f: {0,1}^n --> (0,1)
> is called symmetric if f(x1, ..., xn) = f(sigma(x1), ..., sigma(xn))
> for any permutation sigma, and is called shift-invariant if
> f(x1, x2, ..., xn) = f(x2, x3, ..., x1) = ... = f(xn, x1, x2, ...,
> x_{n-1}).
>
> I am particularly interested in any applications of these functions
> with n>=3. Thanks in advance.
The Trace() function maps {0,1}^n -> (0,1) over GF(2^n). If you
use a normal basis, the output is shift-invariant. I don't understand
what sigma does. If you use a polynomial basis, the Trace() is
not shift invariant, but I can't say I understand "symmetric".
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: breaking xor encryption?
Date: 18 May 1999 14:05:39 -0400
In article <7hqhuv$p08$[EMAIL PROTECTED]>,
Spiffy <[EMAIL PROTECTED]> wrote:
>How does one break the simple xor encryption program?
>...
>What if the person compresses the plaintext and get a real random key?
Breaking such a system involves guessing some of the plaintext at a chosen
spot, determining what the key must be for that spot, applying that key
some distance away in the message (by the length of the key) and seeing
if decrypting at the new spot produces 'plaintext'.
This is much easier if the message is (say) English. The compression makes
the work tougher, but not impossible. No compression is minimal, so there
are always tiny bits of information which must leak out. You can see this
by attempting to decompress completely random bits. Most decompression
programs will complain that the data is corrupt in some manner. The number
of bits leaking out may or may not be enough to reconstruct the key.
A likely area to attack is the very beginning. If I know you are using
PKZIP, I will be able to pull out the first few bytes of your key. Then
I can examine the key itself. If I see that you've chosen an English-like
key phrase, that gives me a handle.
It can be a tedious process depending on what the plaintext is.
>...Could someone easily crack it if it the key
>is 25k (or larger) on a 100k file?
If I know/guess that the underlying plaintext is an English text file,
then I can look at the high bits. I know that all the high bits should
be zero in the file, so I can examine the ciphertext high bits and quickly
determine the length of the key. Now that I know the key is repeated, I
can use the above attack to recover the plaintext in an almost automated
fashion.
>By the way, what are the main implementation/protocol mistakes
>that people make that cause des and other strong algorithms to be insecure?
There was an interesting operating system once which had a correct DES
implementation - all the way down to the parity key bits which are required
by the published standard. Well, another program generated random bits
to use in an encryption and would pass them to the program. It turns out
that the encryption program often rejected the key because the parity bits
were not correct and the encryption was compromised [it was either that
no encryption was done, or that it always encrypted with the same fixed
key. I don't recall the specific details and don't want to point fingers
at an OS incorrectly...]
-Giff
--
Too busy for a .sig
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Musing on and Factoring of a (special) 782-bit Modulus
Date: Tue, 18 May 1999 18:13:40 GMT
Sorry if I reply more than once. Dejanews seems to have thrown
away the others.
Ted Kaliszewski wrote:
> I must admit that I am a bit puzzled by all that erudite
> discussion attending the promotion of a proposed factoring device.
> We hear the usual mantras about the life of the solar system and
> the number of atoms in the universe but nothing about moduli classes
> that can be factored without recourse to special devices or to heavy
> ordnance of the algebraic number theory.
No need to be puzzled. Compute the probability that some
popular RSA keying procedure will produce a modulus of this
special form. Why worry about something that doesn't happen?
> Now, the interesting question remains why is this example
confounding
> the complexity arguments? Perhaps a reader, well versed in that
subject,
> would care to comment.
Doug Gwyn correctly did so.
> PS: Let me anticipate another comment re this posting: one should
always
> avoid special-construction moduli in the on-line commerce.
> Absolutely, provided that one knows what to avoid!
The point is that the RSA key generation procedures _already_
avoid these special classes, and did so before you even
identified them. Currently, there are no known classes of
weak RSA moduli that appear with significant probability.
--Bryan
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: ALF <[EMAIL PROTECTED]>
Crossposted-To: alt.wired,aol.misc,alt.activism,misc.misc
Subject: ALF'S PRIVACY MAIL DROP
Date: Tue, 18 May 1999 12:32:31 -0700
This is a multi-part message in MIME format.
==============41946CB96B7C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
http://members.theglobe.com/lost471/alfmd2.htm
==============41946CB96B7C
Content-Type: text/html; charset=us-ascii; name="alfmd2.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="alfmd2.htm"
Content-Base: "http://members.theglobe.com/lost471/al
fmd2.htm"
<BASE HREF="http://members.theglobe.com/lost471/alfmd2.htm">
<HTML>
<HEAD>
<TITLE>ALF'S PRIVACY MAIL DROP</TITLE>
<META HTTP-EQUIV=REFRESH CONTENT="1500;
URL=http://www.theglobe.com/login/logout.taf?src=hp"></HEAD>
<BODY BGCOLOR=WHITE TEXT=BLACK LINK=BLUE VLINK=PURPLE><SCRIPT LANGUAGE="JavaScript">
<!-- hiding
var remoteWin = null;
var popup_url =
"http://adpop.theglobe.com/popup/default.ad?ord=33763&username=lost471";
if (self.parent.frames.length == 0){
self.name="preview";
}
function popup_hp_ad() {
remoteWin = window.open(popup_url, "ad_popup",
"toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars=0,resizable=0,width=626,height=130");
}
popup_hp_ad();
// End of hiding -->
</SCRIPT>
<noscript>
<CENTER>
<TABLE WIDTH="468" HEIGHT="60"><TR><TD>
<A
HREF="http://ad.doubleclick.net/jump/www.webgenesis.com/hppopup/;sz=468x60;ord=29474">
<IMG
SRC="http://ad.doubleclick.net/ad/www.webgenesis.com/hppopup/;sz=468x60;ord=29474"
WIDTH="468" HEIGHT="60" BORDER="0"></A>
</TD></TR></TABLE>
</CENTER>
</noscript>
<CENTER><TABLE BGCOLOR=yellow BORDER=10 CELLSPACING=2 CELLPADDING=2><TR><TH>
<a href="http://members.theglobe.com/lost471/md.htm">
<img src="http://members.theglobe.com/lost471/md2.gif" alt="ALF'S PRIVACY MAIL
DROP"></table>
<a href="http://members.theglobe.com/lost471/md.htm">Click Here for Web
Site</a></center>
</BODY>
</HTML>
==============41946CB96B7C==
------------------------------
From: [EMAIL PROTECTED] (Cory C. Albrecht)
Subject: Testing my encryption code
Date: Tue, 18 May 1999 19:15:17 GMT
Hello all,
I'm looking to test my own code of some encryption aglorithms that I
have written, and I was wondering if anybody here could point me in the
direction of some clear-text/encrypted-text pairs that I could use to
see if I have gotten things right.
If anybody knows of any such testing lists for the following algorithms
and (where appropriate) DES-type modes, please let me know: Blowfish,
CAST, DES, IDEA, RC2, RC4, RC5, ECB, CBC, CFB, OFB, EDE3.
Thanks in advance.
--
Cory C. Albrecht
http://www.sentex.ca/~cory/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ciphersaber-2 implementation help?
Date: Tue, 18 May 1999 19:04:06 GMT
With the help of Mr. Klassen and Jim Gillogly, a bug was found in the
CipherSaber-2 program that I used to produce the test file. A new CS-2
test file is now available at the CipherSaber Home page http://
ciphersaber.gurus.com
For the curious, the problem occured because the Basic interpreter I was
using implemented its strings internally as C strings. As a result, a
zero in the IV that was generated for the test file was ignored instead
of being incorporated in the RC4 key. The new test file incorporates a
zero in the IV too.
Arnold Reinhold
In article <[EMAIL PROTECTED]>,
"Arthur N. Klassen" <[EMAIL PROTECTED]> wrote:
> If this would be better posted in some other group, please send me a
> clue. I looked but found no other no-brainer location. I'm trying to
> implement CipherSaber-2 and I'm running into problem:
>
> Excerpt from http:
>
> "What is CipherSaber-2?
>
> "CipherSaber-2 is a modification to Ciphersaber-1 that addresses
> concerns raised about possible statistical weaknesses in RC4. In
> CipherSaber-2 the entire state array mixing loop is repeated N times,
> where N is n number that the sender and receiver agree upon. When N=1,
> CipherSaber-2 is the same as CipherSaber-1.
>
> "Used as suggested, there are no known problems with RC4 as it is
> employed in CipherSaber-1, but CipherSaber-2 adds an additional margin
> of safety. See A Cryptanalysis of CipherSaber for more details.
>
> "Here is a sample file encoded with CipherSaber-2 using N = 10 and a
> key of "asdfg":
>
> "0e e3 f9 b2 40 11 fc 3e 2e 00 69 36 45 21 ab 72
> 5a 8f 36 fe 32 89 ac 4f 42 c7 35 1d b5 7a 26 71
> 4b fe ae 66 da e8 f7 49 04 dd"
>
> but I get nothing but french-fries:
>
> C9 36 68 0C 3F 2C F8 C2 0F 14 6B CE 87 BC 78 77
> 55 6C 85 B8 5B 97 17 BD 7B 91 19 95 8A C7 80 AF
>
> I assume the problem is in my setup loop. Here's what mine looks like
> (with some explanatory comments first)
>
> // bMultiScramble is a global meaning use CipherSaber-2
> // nTableScramble is a global for N in CipherSaber-2
> // key is a global where the key+IV is stored
> // kArraySize is a constant for the size of the state array: 256
> // state is a global - the state array
> // keyLength is a global giving strlen(the user's key) + 10
> void Setup()
> {
> if (!bMultiScramble)
> nTableScramble = 1;
>
> const char* pKeyX = key;
> int i, j = 0;
> for (i = 0; i < kArraySize; state[i] = i,++i)
> ;
> for (int k = 0; k < nTableScramble; ++k)
> for (i = 0; i < kArraySize; ++i)
> {
> j = (j + state[i] + *pKeyX) & (kArraySize - 1);
> if ((++pKeyX) - key == keyLength)
> pKeyX = key;
> Swap(state[i], state[j]);
> }
> i = j = k = 0;
> }
>
> I have tried some minor variations, but nothing seems to make the test
> file yield anything meaningful (like a catchy phrase or a gif :). Can
> anyone see what am I doing wrong?
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: Mika Stenberg <[EMAIL PROTECTED]>
Subject: How to understand/program more advanced crypt.
Date: Tue, 18 May 1999 22:02:55 +0300
Hi,
Im really new into Cryptography, and I was wondering if someone could
explain (Maybe with an example program of C / Java / Pascal) how to
code a little more advanced crypt. program. Advanced would mean
something else than just replacing chars with another ones.
Mika
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: prime numbers and the multplicative inverse
Date: Tue, 18 May 1999 19:25:13 GMT
[EMAIL PROTECTED] wrote, in part:
>I haven't been able to find an answer to this question. Why does IDEA
>use a prime field for it's multiplication?
>Does the field need to be prime to have a multiplicative inverse?
Yes. If it is not prime, then numbers not relatively prime to the
modulus have no inverse; if it is prime, every nonzero number has an
inverse.
This is explained on the section of my web page about IDEA.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: prime numbers and the multplicative inverse
Date: Tue, 18 May 1999 19:26:46 GMT
Bob Silverman <[EMAIL PROTECTED]> wrote, in part:
>I'm not sure I understand the question. Do you mean why it uses
>GF(p) as opposed to GF(2^n)?? Or do you ask why it uses a finite
>field in the first place?
Why it needs to use GF(65537) and wouldn't work if 65537 wasn't a
prime number. And he said "field" when he meant "group".
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Can Somebody Verify My DES execution?
Date: 18 May 1999 18:52:27 GMT
According to wtshaw <[EMAIL PROTECTED]>:
> Having written dozens of different encryption programs, I know that more
> comprehensive evaluation is needed.
In the case of DES, given the structure of the algorithm, a good test is
to perform a few thousands successive executions. This should try all
permutation bits and lookup table values, and DES is designed so that
any subtle difference in the input should give a very different output.
If a DES implementation passes this test, it is with high probability
correct(*). Note that this is not true for all ciphers; for instance,
DFC (a candidate for the AES) uses a modular reduction modulo 2^64+13,
and my first implementation add a bug that would appear only once every
2^61 encryptions on average, which is hard to find with a generic and
simple test.
For DES, 16384 successive encryptions:
key : 01234567 89abcdef
plain : 01234567 89abcde7
cipher : 907d749c 5e704d28
--Thomas Pornin
(*) I mean that I would then trust it more than the processor it is
running on. It is useless to go beyond that point.
------------------------------
From: [EMAIL PROTECTED] (Chris Monico)
Subject: Re: prime numbers and the multplicative inverse
Date: Tue, 18 May 99 00:12:02 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>>
>> I haven't been able to find an answer to this question. Why does
IDEA
>> use a prime field for it's multiplication?
>>
>> Does the field need to be prime to have a multiplicative inverse?
>
>Prime fields have multiplicative multiplicative inverses. I.e., the
>inverse operation is multiplication by another value rather than
>division by the orginal multiplier.
Huh? Any field has that. a/b is defined as a*b^{-1}. Even Q is defined
that way- it is the quotient field of Z.
------------------------------
From: [EMAIL PROTECTED] (Chris Monico)
Subject: Re: prime numbers and the multplicative inverse
Date: Tue, 18 May 99 00:06:55 GMT
In article <7hrgi1$1or$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>I haven't been able to find an answer to this question. Why does IDEA
>use a prime field for it's multiplication?
>
>Does the field need to be prime to have a multiplicative inverse?
>
>Tom
I'm not familiar with IDEA, but every non-zero element in _any_ field
has an inverse.
------------------------------
From: [EMAIL PROTECTED] (RREYNARD)
Subject: Re: where can i find a frequency list?
Date: 18 May 1999 20:02:19 GMT
>i used to have a book that had marvellous frequency tables, digraphs,
>double letters, etc. the book was stolen from me a long, long time ago
>and i can't remember what the title was.
Classic Crypto Books ([EMAIL PROTECTED]) probably has a reprint of that book and
certainly has other books that contain all that you mentioned and more.
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: How to understand/program more advanced crypt.
Date: Tue, 18 May 1999 14:25:27 -0700
"Applied Cryptography" by Bruce Schneier is a really good introduction to
cryptography and it contains the source code to many of the algorithms that
are discussed in the book.
"The Handbook of Applied Cryptography" by Alfred Menezes, Scott Vanstone and
Paul van Oorschot offers a more in-depth technical introduction but there is
no C source code.
Good luck.
-steven
------------------------------
From: "Tim Mavers" <[EMAIL PROTECTED]>
Subject: Re: Need to design basic authentication system
Date: 18 May 1999 16:34:15 -0500
Mark Carroll wrote in message ...
>In article <mXg%2.16606$[EMAIL PROTECTED]>,
>So, tell us more about the mode of deployment. Does any shared secret
>at all exist between the user and server prior to the first password?
>And is the network between them one that the attacker can listen in on
>but not actually fiddle with, or what?
Basically it's a client/server setup with the server being located anywhere.
Most like it will be in a company intranet, but there is a possibly of
someone connecting to the "company net" from their local ISP or something
insecure like that.
Actually, I am still concerned with intranet security as software sniffers
are pretty common (and easy to use) nowdays. I am a bit uncomfortable with
the initial password sent in an insecure way initially. If I was sniffing,
I would just analyze the data for a few days and then I need not be worried
about the hashing done as I would just watch for a "new user" signing on.
The system is designed for employees to use on a daily basis. A local admin
can add/remove users at will and will probably do so quite frequently
(people being hired, quitting, moving to different project, etc.). So
there's a good possibility that watching the net for just a few days will
reveal a weak-packet with the password.
There really is no shared secret between the server and client initially.
As I mentioned earlier, the server could exist in a different country and it
might be a bit harder to exchange new user passwords. Then again, maybe
having the user create a new acct shouldn't be allowed and the admin should
do it and transmit the password in a secure means (or whatever way they
want).
Thanks...
------------------------------
Date: Tue, 18 May 1999 17:39:24 -0400
From: [EMAIL PROTECTED]
Subject: Re: True Randomness & The Law Of Large Numbers
Well, <plonked> three times so far by Knauer. Is this a record?
R. Knauer wrote:
>
> On Sun, 16 May 1999 11:00:35 -0400, [EMAIL PROTECTED] wrote:
>
> >> "The frequency concept based on the limiting frequency as the number
> >> of trials increases to infinity does not contribute anything to
> >> substantiate the application of the results of probability theory to
> >> real practical problems where we always have to deal with a finite
> >> number of trials."
> >> --Kolmogorov (quoted in Li & Vitanyi, p. 55)
>
> >This is a matter of opinion not science. And he's wrong.
>
> I just love this! Usenet Twats taking on the giants of mathematics.
>
> Such utter arrogance is unsurpassed anywhere else in the history of
> science.
>
> >> "We shall encounter theoretical conclusions which not only are
> >> unexpected but actually come as a shock to intuition and common sense.
> >> They will reveal that commonly accepted notions concerning chance
> >> fluctuations are without foundation and that the implications of the
> >> law of large numbers are widely misconstrued. For example, in various
> >> applications it is assumed that observations on an individual
> >> coin-tossing game during a long time interval will yield the same
> >> statistical characteristics as the observation of the results of a
> >> huge number of independent games at one given instant. This is not so.
> >> Indeed, using a currently popular jargon we reach the conclusion that
> >> in a population of normal coins the majority is necessarily
> >> maladjusted."
> >> --Feller, p. 67.
>
> >Shock value. Exaggeration in order to provide drama. It works for
> >books just as it does for TV shows and movies. But we only expect
> >10-year-olds to be taken in by these techniques.
>
> LOL
>
> >Grow up.
>
> You grow up.
>
> <plonk>
>
> Bob Knauer
>
> "There is much to be said in favour of modern journalism. By giving us the opinions
> of the uneducated, it keeps us in touch with the ignorance of the community."
> -- Oscar Wilde
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Quadibloc III errors corrected
Date: Tue, 18 May 1999 21:34:23 GMT
A new variation of Quadibloc III was added, following the principles
of "Layered Design" mentioned in a recent post. GoodStuff was moved
outwards, leaving Mishmash in the very middle.
Also, the changes to the key augmentation portion of the key schedule
required to allow that variation, and other variations, were
described.
An error in a diagram of a Mishmash variation, which showed a 64-bit
quantity being enciphered by a 32-bit block cipher, was corrected.
In addition, elsewhere on the site, a few comments were added to my
description of SKIPJACK, reflecting the insight the boomerang attack
gave on its design.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
** 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
******************************
