Cryptography-Digest Digest #973, Volume #10 Tue, 25 Jan 00 16:13:01 EST
Contents:
Re: NIST, AES at RSA conference (David A Molnar)
plaintext/ciphertext/keys needed for testing ([EMAIL PROTECTED])
Re: Modem Crypto (Military Grade) (John Savard)
Re: Does RSA use real prime ? (James Felling)
Re: Java's RSA implimentation (Paul Schlyter)
Re: Reversibly combining two bytes? (Terry Ritter)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Reversibly combining two bytes? (Terry Ritter)
Re: MIRDEK: more fun with playing cards. (Rex Stewart)
Re: Does RSA use real prime ? (Tom St Denis)
Re: Does RSA use real prime ? (Tom St Denis)
Re: Why did SkipJack fail? (Paul Koning)
Re: Why did SkipJack fail?
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: 25 Jan 2000 19:02:35 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
> unrelenting long-term effort of a well-funded task force made up of
> many minds. We should not be asking for more crypto-gods; we should
> instead be funding crypto R&D and -- like magic! -- new crypto-gods
> will appear.
Are the research teams at companies like Bell Labs and IBM T.J. Watson
along what you have in mind?
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: plaintext/ciphertext/keys needed for testing
Date: Tue, 25 Jan 2000 19:33:27 GMT
Hey all.
Looking for known plaintext/ciphertext/keys/IVs for the following
algorithms. Email to this account would be prefered. I'm not
necessarily looking for someone to type all of it out for me, but
references to known values would be a definite time-saver.
RSA, RC2, RC4, RC6, RC6 (AES), DES, 3DES, Blowfish and CAST-128.
I have found a number of others (Mars, Rijndael, Twofish, etc) but
looking for the above algorithms in particular.
Any help in pointing me to some clear documentation would be most
appreciated. I'm not a math scholar nor a certified cryptanalist, so go
easy on me! ;o)
-id
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Modem Crypto (Military Grade)
Date: Tue, 25 Jan 2000 12:54:53 GMT
"Steve Sampson" <[EMAIL PROTECTED]> wrote, in part:
>The analog portion of even the ISDN STU can only do 9.6k max, which is all
>right for a BBS application, but inadequate for PPP.
I'd imagine that if you want to use analogue telephone lines, but you
want to use them for, say, a 28.8 digital connection, what you would
have to do is encrypt the digital data before it gets to the modem;
digitizing the analogue modem output and encrypting it, as opposed to
digitizing the human voice (which can be done at varying levels of
quality into rates as low as 2400 baud) would require a very high
bandwidth connection indeed.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Does RSA use real prime ?
Date: Tue, 25 Jan 2000 13:58:06 -0600
Ok. A reasonable estimation is a failure 1 in 10^44 pairs generated. If
you generate 10 key pairs for every person on the planet every second,
then you have a negligable potential for 1 such pair 10^20 or so years.
Works for me.
Greg wrote:
> > First off the primality testing on PGP is such that the
> > odds of you winning the lottery jackpot within 5 seconds
> > of being struck by lightning is a much more likely
> > occurence than a PGP chosen pair of primes containing
> > a composit number.
>
> And how remote is that? Is it as remote as someone winning the
> lottery in CA twice in one decade? That has happened. :)
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Java's RSA implimentation
Date: 25 Jan 2000 19:08:57 +0100
In article <[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
>> If there are no way to copy the array (except in a loop where each
>> array element is copied, one by one), arrays aren't first class
>> citizens in the language. That's the situation in C and C++.
>
> Interesting definition. By that definition, Python arrays don't qualify as
> "first class" either, since 'ary1=ary2' simply makes ary1 refer to the same
> array object that ary2 refers to (everything is an object in Python -- there
> are no "simple" variables). Perl's arrays do. Yet, as far as I can tell, both
> languages are roughly equivalent in their ability to manipulate arrays. The
> only thing that differs is that Python gives special treatment to "immmutable"
> variables (strings and numbers) and does a copy rather than a reference.
That's the definition used when talking about C. One example:
struct str { int a; };
void foo()
{
int A[100], B[100], *C;
struct str X, Y;
......................
/* Legal - C becomes a reference to A or B; no copy is made */
C = A; C = B;
/* All illegal -- A and B are constant pointers which cannot be changed */
A = B; A = C; B = A; B = C;
/* Legal, since struct's are first class citizens in C: a copy is made */
X = Y; Y = X;
}
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Reversibly combining two bytes?
Date: Tue, 25 Jan 2000 20:16:09 GMT
On Tue, 25 Jan 2000 17:05:40 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
>Alan Lawrence <[EMAIL PROTECTED]> wrote:
>
>[Terry Ritter suggested the use of a randomly-constructed Latin Square]
>
>: Latin squares can, in effect, hold the details of how to encrypt and
>: decrypt by _any_ reversible method, i.e. one could construct a Latin
>: Square, the output of which is equal to the sum of the column number and
>: row number. Obviously a Latin square with no simple relationships, and
>: non-linear combining is far superior....however how do I generate such a
>: square? If I find suitable seeds for a random number generator, I can
>: permute the sequence 0..255 to generate a column of the table, and do this
>: 256 times, but then how do I make sure each number appears exactly once in
>: each row as well? Admittedly one could brute force this, repeatedly
>: generating the table until it works, but being fussy I don't like doing it
>: that way:-)
One can compromise on using less data, but with more of a relationship
between the columns. Of course there is always *some* relationship
between columns; if we know n-1 columns for any row, we know entry n.
>The problem is perhaps not /quite/ as bad as you make out.
>
>Here's one (probably highly sub-optimal) way of doing it:
>
>As you say, you can generate a single column of 256 bytes which is a
>permutation - by repeatedly swapping individual entries at random a large
>number of times.
>
>Generate one column first - by swapping lots of random rows entries.
>
>On subsequent colums, swap random row entries, with the constraint that
>you never swap a number into the same position as it is in, in any of
>the previous entries in that row.
>
>Repeat until done.
>
>This will produce a rather random Latin Square. Of course, there is
>*some* chance that this will be a linear table - but in a 256x256 table,
>this chance is pretty remote.
We can improve efficiency by keeping lists of the symbols and
positions used in rows and columns, and choosing the most-constrained
element for a random fill. Some backtracking is inevitable in a
random construction. Years ago, on a 90 MHz Pentium, I could do a
random order-256 Ls in about a minute.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Tue, 25 Jan 2000 20:23:59 GMT
On 25 Jan 2000 19:02:35 GMT, in <86ks0b$hii$[EMAIL PROTECTED]>,
in sci.crypt David A Molnar <[EMAIL PROTECTED]> wrote:
>Terry Ritter <[EMAIL PROTECTED]> wrote:
>> unrelenting long-term effort of a well-funded task force made up of
>> many minds. We should not be asking for more crypto-gods; we should
>> instead be funding crypto R&D and -- like magic! -- new crypto-gods
>> will appear.
>
>Are the research teams at companies like Bell Labs and IBM T.J. Watson
>along what you have in mind?
Well, yes and no: It's always nice to have more research. But
usually research is directed to some extent along product lines. With
little or no industry of cipher sales, I expect that there is minimum
support for research and the development directed at new ciphers.
The "current wisdom" seems to be that one good cipher is enough, and
if this were possible I would agree. The problem is that -- absent a
mathematical breakthrough -- we can never know if a cipher really is
"good"; thus we can never get that "one good cipher."
What all this means to me is that we dare not trust any single cipher,
and that means we need a for-profit industry of continued cipher
development with associated R&D.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Reversibly combining two bytes?
Date: Tue, 25 Jan 2000 20:49:23 GMT
On 25 Jan 2000 17:04:53 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Michael Wojcik) wrote:
>[...]
>Just off the top of my head:
>
>Generate one permutation 0..255. Call it P.
>Generate a second permuation 0..255. Call it R.
>
>For each column C[i=0..255], rotate P by R[i]. The rotation can be
>trivially computed while populating C by using (index + R[i]) mod 256
>to index P.
>[...]
>Since all columns are different rotations of the same permutation,
>no two columns will be the same, and no two columns will have the
>same value x in a given row r, so no row will have a repeated
>value.
>
>I've only given this cursory thought; it may be broken or weak.
Upon cursory reading :-), it looks like it ought to work, and I
haven't seen it before. There is of course more of a relationship
than in a true random construction. But it might be interesting to
investigate Boolean nonlinearity values in the squares produced by
this method, and compare the distribution to that which occurs in
random squares.
Naturally, for any fixed table, if the opponent can traverse and
identify a substantial portion of the table, or maybe just the part
most commonly used, not much strength can remain. Ideally we will
select among a multiple keyed squares, used in several sequential
levels, for each character ciphered.
Question: Can the given method be generalized to construct orthogonal
Ls's?
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Tue, 25 Jan 2000 20:42:15 GMT
I think I see your point. I didn't see it yesterday, but
a string of the same letter would be a problem - assuming
the adversary knows you are encrypting a repeating letter.
While this in itself would not be a disaster (any agent
who falls to this is not much of an agent), it may be
an indicater of another - more useful attack :-(
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Rex Stewart <[EMAIL PROTECTED]> writes:
> > > I strongly suspect that a chosen plaintext attack would choose the
> > > plaintext "AAAAA...." since that makes least use of the state of
the
> > > left deck.
> >
> > > Oh bugger. If you guess where this letter appears in the left
pile,
> > > then you can infer the state of the right deck within 25
characters,
> > > and thus get the state of both decks in 50. If you're using
Mirdek -
> > > don't encrypt the sequence "A" x 50 :-)
> >
> > I don't think this is the case - as you say IF you guess where this
> > letter appears in the left pile. And do it 25 straight times.
>
> It's even worse than I'm imagining. If you know the plaintext is a
> stream of 'A's, then each ciphertext letter tells you where the A
card
> was immediately before the letter search. After the letter search,
of
> course, the A will be as far from the bottom as it was from the top.
> So you know where the A is before and after the count cut, from which
> inferring the discarded card is trivial. After 51 ciphertext letters
> you have the state of the entire deck. No need to guess anything.
>
> What I'd like to do to fix this is to replace the count cut with a
> different kind of letter search, but I can't think of a search with
> the right properties:
>
> * dependent on the position of the searched-for letter, not the
letter
> searched for
>
> * reversible, given the searched-for letter
>
> * for each card in the old state of the left deck, every new position
> is equiprobable
>
> * ideally it would do some mixing too
>
> Actually, I can think of one but it's unwieldy: just cut cards from
> the top to the bottom until the searched-for card is as far from the
> bottom as it was from the top (ie one card if it's on the top, three
> if it's second, 5 if third etc). Better suggestions would be very
> welcome!
> --
> __
> \/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
> /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Does RSA use real prime ?
Date: Tue, 25 Jan 2000 20:42:39 GMT
In article <86kpkd$nq1$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
>
> > So I repeat. If p or q are not prime, encryption/decryption will
not
> > work for the most part [it may work once with a slight possibility].
> > So you must find new primes.
>
> So are you saying that all one has to do is randomly select a p
> and a q and try to encrypt and then decrypt some random data say
> a half dozen times and if it works well, then p & q are useable?
i am saying: pick two primes and multiply them together.
> I have never heard of this relationship you are describing before.
It's called math you should try it.
If p and/or q is/are not prime then the inverse key 'd' (of 'e') modulo
(p - 1)(q - 1) will not decrypt when you use it.
So you can be reasonably sure that if the two numbers are not prime
that encryption can't work.
By deduction PGP does work, therefore with a very high probabilty the
keys moduli are the result of two primes being multiplied together.
I suggest you study the Pohlig-Hellman cipher. It works like this.
1. Pick a 'p' which is a large prime.
2. Pick a random 'e' which is relatively prime to 'p - 1'
3. Pick 'd' such that 'de = 1 mod (p - 1)'.
To encrypt just do C = M^e mod p
To decrypt just do M = C^d mod p.
The order of the group [the higest power possible] for a prime modulus
is the prime minus one. In this case p-1. Therefore your numbers must
merely be multiplicative inverses modulo p-1. If you can't see it try
this.
M = M^d^e mod p
M = M^de mod p
M = M^1 mod p
M = M
Try it in the set of real numbers using
e = some integer
d = 1/e
Like e=5, d=1/5
M = 20
C = M^5 = 3200000
M = C^1/5 = 20
Now try it where d is not the multiplicative inverse... say d = 1/3
M = C^1/3 = ~147.36...
Ooops.. doesn't quite work.
anyways... nuff of me. There is more theory behind it. But I am
a 'uneducated type' so that's it for me.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Does RSA use real prime ?
Date: Tue, 25 Jan 2000 20:46:01 GMT
In article <86kqcs$ohq$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
>
>
> > First off the primality testing on PGP is such that the
> > odds of you winning the lottery jackpot within 5 seconds
> > of being struck by lightning is a much more likely
> > occurence than a PGP chosen pair of primes containing
> > a composit number.
>
> And how remote is that? Is it as remote as someone winning the
> lottery in CA twice in one decade? That has happened. :)
What you have Mr. Greg is a failure to realize what is important.
The chances that two numbers sneak thru a primality test, and that they
can be successfully be used in a cryptosystem like RSA or DH is so
remote that the chances of martians winning the next election seems
plausible.
I would guestimate about 5 million RSA keys are in active use, and I
would still say the chances that one of them is 'compromised' is so
remote that one of them martians would more likely will become mayor
first...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Tue, 25 Jan 2000 15:56:48 -0500
Paul Rubin wrote:
> ...
> >OTOH, it almost makes it easier to build a truly huge number of
> >encryption engines on a relatively small number of chips if you decide
> >to break SkipJack by exhausting the keyspace.
>
> It probably needs around the same amount of chip area as DES.
> DES was designed for hardware implementation. Skipjack appears
> designed for 8-bit microcontroller software implementation.
>
> >Combining these two factors leaves me, for one, with a feeling that
> >SkipJack probably doesn't provide particularly good long-term
> >security. Even in the short term, I'd be quite hesitant to use it for
> >protecting extremely sensitive data.
>
> That is a wise assessment. It still leaves lots of data for which
> Skipjack's security is more than good enough. Remember that
> distributed.net (the "world's fastest computer") has been crunching a
> single RC5-64 message for *years* and has searched only a small
> fraction of the 64-bit keyspace. I think it will be a long while
> before anyone can break Skipjack messages in "production" volumes.
That isn't terribly relevant. Deep Crack is enormously faster than
distributed.net, and you could easily get two or three orders of
magnitude today without a whole lot more money for ciphers like
DES that take few gates and parallelize well. RC4 (did you mean
RC4 rather than RC5?) is much harder to attack fast in hardware.
I suspect a major reason why Skipjack failed is that it was
classified until a year or so ago. So by the time it was finally
published, no one cared anymore. At least not enough to adopt it.
If it had been made public when first proposed, things might have
been different, although even then the taint of Clipper would have
been a big issue.
paul
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Tue, 25 Jan 2000 22:09:31 +0100
On Tue, 25 Jan 2000, Greg wrote:
>
> Can anyone please share their views on why SkipJack failed in
> the market place?
>
Most modern ciphers are as strong as or even stronger than Skipjack
against all known attacks.
Since Skipjack was developed by NSA it may be strong against attacks
unknown to the rest of the world, but there may as well be a hidden
weakness. I don't think anybody would use an NSA-cipher if he get's
something comparable developed by a well-known cryptographer.
Another important point is the small key: 80 bit may be anough to
protect a secret for several years, but bits are cheap and there are lots
of ciphers with much longer keys. Huge keysizes sound always good :-)
The good point on Skipjack is the small amount of memory it needs. But the
difference to some others like GOST are as well fine for smartcards and as
well for hardware-implementations as on larger computers other ciphers are
much more efficient.
Enterrottacher Andreas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
** 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
******************************
