Cryptography-Digest Digest #680, Volume #12 Thu, 14 Sep 00 16:13:01 EDT
Contents:
Re: SDMI Crypto Challenge ("David C. Barber")
Re: For the Gurus (/dev/null)
Re: Fresh Meat: New Crypto Algorithms Announced ("Brian Gladman")
Re: Announcement (Mike Rosing)
Re: For the Gurus (/dev/null)
Re: Announcement (Jerry Coffin)
Re: Intel's 1.13 MHZ chip (Jerry Coffin)
Re: For the Gurus (Jim Gillogly)
Re: GSM tracking (Mike Rosing)
DH -> 3DES ([EMAIL PROTECTED])
Re: For the Gurus (Jim Gillogly)
Re: Hash algorithms (Bill Unruh)
Re: RSA Questions (Bill Unruh)
Re: sac fullfilling decorelated functions (Tom St Denis)
Re: DH -> 3DES (Tom St Denis)
----------------------------------------------------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: SDMI Crypto Challenge
Date: Thu, 14 Sep 2000 10:10:35 -0700
Right, sorry. And sorry for the duplicate post. My posting program/news
server was having problems at the time and I wasn't sure either post got
out.
I like having my mistakes corrected. Makes me want to be even more careful
next time.
*David Barber*
"Jim Gillogly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Jim Gillogly wrote:
> >
> > "David C. Barber" wrote:
> > >
> > > The music industry is paying (underpaying) $10K for anyone who can
defeat
> > > the SDMI-II proposals. Visit www.hacksdmi.com for info.
> >
> > There are no details at http:// www.hacksdmi.com yet, so I don't know
> > whether they're planning to make the algorithms and/or source code
> > available, or whether it's another of these bogus CYA "Here's some
> > content, can you read it?" challenges. In any case, they're allowing
> > only three weeks, so I'm guessing they aren't hoping for real
information.
>
> Sorry, that should be http://www.hacksdmi.org .
>
> --
> Jim Gillogly
> Highday, 23 Halimath S.R. 2000, 10:51
> 12.19.7.9.17, 6 Caban 20 Mol, Eighth Lord of Night
------------------------------
From: /dev/null <[EMAIL PROTECTED]>
Subject: Re: For the Gurus
Date: Thu, 14 Sep 2000 13:19:39 -0400
Here is my current thinking... feel free to shoot as many holes in it
as possible, I've been flame proof since a mis-translation I did in
1975. :)
-m-
Using the following frequencies as
a guide to inscribe the plain text
into a 6x6 matrix. The matrix may
or may not be changing slightly but
in the final design I intend to hold
it constant.
ETNORI ASDLFH MPUCGW YBVJKQ XZ
13 7 3 2 0
This example is trivialized by not
using a randomized key alphabet.
Plain | ROW KEYS
-------|
ETRLC0 | ABCDE
NOSFW2 | FGHI
IADPB4 | JKL
HMUJK6 | MN
GYVQXZ | OP
135789 | QR
----------------
STUVWX COL KEYS
YZ0123
456
78
9
P(E) = c(AS, AY, A4, A7, A9, ..., 9E)
P(9) = c(QX, Q3, XQ, XR)
Ex:
P(N O T T O D A Y F R I E N D )
C(FS GT E8 C5 I5 KU JT TP GV C0 L7 C9 HY KU)
The key alphabet consists of A-Z
and 0-9. Alphabets are generated
by machine using the high order bits
of the Unix rand() function and the
following fragment of code.
x = (rand() >> (rand()%23));
This is then manipulated into a char
and if the char it represents has not
already been assigned as a member of
the key stream it is assigned. If it
has already been assigned it is tossed
and the next number is tried. Fragment:
...
c = toupper((char) x);
for (ix=0; ix< strlen(key)) {
if (key[ix]==c) break;
}
if (ix == strlen(key)) {
key[ix]=c;
++ix;
key[ix]=NULL;
}
return;
...
The random number generator is
initially seeded with a random string
generated on the keyboard. After a
key is generated the random number
generator is re-seeded with the first
few bytes of the key and the next key
is generated.
If a method to ensure the user never
used a cipher/plain pair twice were
established, what key change criteria
would improve the security of this
system? Can this system ever be
secure against a dedicated professional
with unlimited resources?
> --
> If children don't know why their grandparents did what they
> did, shall those children know what is worth preserving and what
> should change?
>
> http://www.cryptography.org/getpgp.htm
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Fresh Meat: New Crypto Algorithms Announced
Date: Thu, 14 Sep 2000 18:30:14 +0100
"John Myre" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Bruce Schneier wrote:
> >
> > The European Telecommunication Standards Institute (ETSI) has made a
> > bunch of encryption algorithms public:
> >
> > <http://www.etsi.org/dvbandca/>
>
> Well, semi-public. It costs a money and you have to sign a
> license agreement. See the "conditions" links (Microsoft Word
> documents, sigh). I see prices of 100 and 1000 EURO's; I think
> this is per algorithm.
But the specifications for some of them have been made available for
downloading without charge at:
http://www.etsi.org/dvbandca/3GPP/3gppspecs.htm
Use of the algorithms is restricted and I assume that the charges apply for
use rather than study.
I have written to ETSI to ask if this is correct.
Brian Gladman
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Announcement
Date: Thu, 14 Sep 2000 12:28:02 -0500
Dido Sevilla wrote:
>
> rosi wrote:
> >
> > ROSi has decided to venture past concept into implementation.
> >
>
> Does anyone know what the heck this person is talking about?
Nope, and I intend to keep it that way!
Patience, persistence, truth,
Dr. mike
------------------------------
From: /dev/null <[EMAIL PROTECTED]>
Subject: Re: For the Gurus
Date: Thu, 14 Sep 2000 13:23:45 -0400
wtshaw wrote:
>
> The key for BLT is a deranged 27 character alphabet, even derived from a
> pangram if desired.
> --
> Rats! (What Gov. Bush is apt to say the morning after the election)
Ya, dang liberal! :)
I am sure ticked off at Bush now that he is trying to justify the use
of subliminals in his ads... What is he thinking? I wish we 'publicans
had chosen the other fellow.
Tell me more about your BLT cipher.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Announcement
Date: Thu, 14 Sep 2000 11:31:19 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> rosi wrote:
> >
> > ROSi has decided to venture past concept into implementation.
> >
>
> Does anyone know what the heck this person is talking about?
>From the looks of it, I doubt it -- and I include the poster in the
group of those who don't know what s/he's talking about.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Thu, 14 Sep 2000 11:31:18 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> That the PC-chips become very fast have two implications.
> First, it is possible to use lots of them to obtain rather
> cheap supercomputing power (for appropriate programs) that
> was not possible previously.
Back when the Cray 1 was brand new, there was an article in Byte
Magazine (I think it was Byte anyway -- it was long enough ago that
my memory might be a bit off) talking about how you could build an
equivalent out of a LOT of Apple II's. In short, the target may be
higher now, but the idea of building a supercomputer out of a lot of
tiny machines is definitely OLD.
> Second, because of that, the
> export bans of supercomputers to the unfriendly nations are
> no longer very effective. (I read somewhere, though, that
> the export bans as such were at no time absolutely effective
> as a matter of fact.)
I'm convinced that export bans never were effective at all. Call me
cynical if you will, but I've always been convinced that they were to
allow ignorant politicians say "ours are bigger than theirs", not to
protect national security at all.
Then again, I'm convinced that the NSA buying as many Crays and such
as it did was largely for the same reason. They undoubtedly found
reasonable uses for them afterwards, but I think the original
purchases were done because DIRNSA wanted things to show off to the
other generals when they came through on tours.
The usual thing for generals to brag about is the number of people
they have under them, but DIRNSA couldn't play that game (the numbers
are classified, and almost certainly too small to be impressive
anyway). Therefore, since he couldn't compete directly with them, he
get something they couldn't. Though I gave rational reasons for
cancelling Cray IV orders previously, I strongly suspect a lot of the
REAL reason they cancelled the orders was that Cray IV's were enough
smaller than they just didn't LOOK so impressive anymore...
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: For the Gurus
Date: Thu, 14 Sep 2000 17:39:25 +0000
/dev/null wrote:
>
> Nice work. HOOSIER. Pattern lists or machine assist?
Shotgun hillclimbing with tetragraph evaluation function and
assumed coherent key, scored as part of the recovered "plaintext".
As my subsequent message indicated, keyword search also works fine.
Pattern lists are easier to apply if word divisions are present,
and wouldn't have been terribly informative with these particular
patterns in any case.
> Jim Gillogly wrote:
>
> > "root@localhost " wrote:
> > > Even a monoalphabetic substitution system can be secure under the right
> > > conditions. For example, what does this say? LMUU MEOZ AQDR LEXX It
> > > is a simple keyword based mono-alphabetic substitution cipher.
> >
> > "Not today, friend." Keyword KOSHER. (Or, equivalently, GOITER or HOSIER
> > or a host of others.)
--
Jim Gillogly
Highday, 23 Halimath S.R. 2000, 17:34
12.19.7.9.17, 6 Caban 20 Mol, Eighth Lord of Night
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: GSM tracking
Date: Thu, 14 Sep 2000 12:41:13 -0500
Arturo wrote:
>
> I know that a mobile phone can be tracked while being used. But there�s
> something I�m not sure about: can a GSM phone be tracked when it�s off, or is it
> necessary to plug the battery away?
It can be tracked while powered up and not under use, but that information is
presently not sent out of any base station. It's only used if a call to that
phone is requested by the central switch. This is something the cell phone
companies are complaining about, it would cost too much to send that data up
the chain.
If the phone is *off*, i.e. no power at all, then it can not be tracked.
>
> Also, has the tracking capability been already requested by law
> enforcement bodies (e.g. FBI), or is it the next gift they�ll ask from Santa?
Yes, this is part of CALEA and one of the main reasons it hasn't been implemented
yet. The cost of putting it in far exceeds what the taxpayers are willing to
pay :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: DH -> 3DES
Date: Thu, 14 Sep 2000 17:44:22 GMT
I'm looking for a reference on how to exchange 3DES keys with Diffie
Helman. What size prime should the DH use to be stronger than 3DES?
Should I just take the first 24 bytes of the DH computed key as the
computed 3DES key or is more processing necessary?
Should I check for weak DES keys?
Adjust parity?
Roger
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: For the Gurus
Date: Thu, 14 Sep 2000 17:56:43 +0000
/dev/null wrote:
> This example is trivialized by not
> using a randomized key alphabet.
>
> Plain | ROW KEYS
> -------|
> ETRLC0 | ABCDE
> NOSFW2 | FGHI
> IADPB4 | JKL
> HMUJK6 | MN
> GYVQXZ | OP
> 135789 | QR
> ----------------
> STUVWX COL KEYS
> YZ0123
> 456
> 78
> 9
>
> P(E) = c(AS, AY, A4, A7, A9, ..., 9E)
> P(9) = c(QX, Q3, XQ, XR)
OK, this is a Checkerboard cipher with known row and column
keys (Kerckhoffs' Law, the opponent knows everything except
the day's key).
> The key alphabet consists of A-Z
> and 0-9. Alphabets are generated
> by machine using the high order bits
> of the Unix rand() function and the
> following fragment of code.
>
> x = (rand() >> (rand()%23));
I had assumed the method was supposed to be memorized, perhaps
so that no incriminating evidence would be found on the user.
However, if the user will have a Unix box available at encryption
time, why not run a good encryption system on it then? If they
will be carrying incriminating material, why not a Palm Pilot?
I still haven't seen the operating conditions and threat environment
specified.
> If a method to ensure the user never
> used a cipher/plain pair twice were
So in this particular case no message can use more than four 9's?
Hurm... that can limit the kinds of messages you will send.
> established, what key change criteria
> would improve the security of this
> system? Can this system ever be
> secure against a dedicated professional
> with unlimited resources?
No. Unix rand() typically uses 32 bit seeds, which is within the
range of brute force attack, so even short messages will be toast.
Assuming a 64-bit Unix were in use, it will still be crackable
using a known plaintext attack: once a bunch of letters in the
matrix are filled in, the known rows and columns give away enough
of the alternate digraphs that the whole thing will fall apart.
--
Jim Gillogly
Highday, 23 Halimath S.R. 2000, 17:47
12.19.7.9.17, 6 Caban 20 Mol, Eighth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Hash algorithms
Date: 14 Sep 2000 18:01:46 GMT
In <4yUv5.62062$[EMAIL PROTECTED]> <[EMAIL PROTECTED]> writes:
>I have a project that requires me to look into 5 hash algorithms, I have
>been attempting to figure out what exactly is a hash algorithm. I know that
>MD2-5 are one-way hash algorithms, but what would the definition be of a
>hash algorithm so I can identify the other 4 that I require?
Something which maps a long message onto a short on, usually of fixed
length. For example, taking the first two bytes of a messages is a 16
bit hash. (not cryptographically secure, but useful in dictionaries, and
web pages). Secure hash functions also have the feature that it is
difficult to find two messages which have the same hash output.
Sometimes (eg spell checkers) the hash should make it easy to find
another (correctly spelled) output for a given input.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RSA Questions
Date: 14 Sep 2000 18:12:59 GMT
In <[EMAIL PROTECTED]> Future Beacon
<[EMAIL PROTECTED]> writes:
]Does anybody know what goes wrong with RSA
]if p or q or both are not necessarily prime?
Easier to crack. The more factors N has the smaller they are and the
easier they are to find. Also, ed!=1 mod(p-1)(q-1) but mod (r-1)(s-1)...(q-1)
I believe.
]Surely there is still a way to select a d such
]that decryption works for the receiver.
]If RSA becomes weaker, does anybody know how
]messages would be decrypted without d?
RSA becomes weaker? Do you mean with N composite with more than 2
factors? factoring becomes easier, so finding d from N and e becomes
easier.
]I ask these questions because the strength of RSA seems
]to depend upon the size of the numbers. The numbers encrypted
]by RSA must be large; otherwise, a table could be made of the
]number range mapping the plain text to the ciphertext and the
]difficulty of factoring would be irrelevant. Meanwhile, the
That is NOT the problem. The size of such a table is 2^(2N) where N is
the length of the number. Even for a 64 bit output like DES, this is
hopeless. The lenght is dictated by the ease of factoring smaller
numbers.
]numbers encrypted must be smaller than pq or they will not be
]reported correctly to the person who holds d. This means that pq
]must be large to avoid a table-making attack.
table making works only for cyphers with a very small output block.
]If the game is merely outrunning current computers, what is the
]significance of p and q being prime?
factoring.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: sac fullfilling decorelated functions
Date: Thu, 14 Sep 2000 19:29:30 GMT
In article <[EMAIL PROTECTED]>,
Serge Vaudenay <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Serge Vaudenay <[EMAIL PROTECTED]> wrote:
> > >
> > > It is actually a little tricky.
> > > If you consider differential cryptanalysis with any input
difference a
> > > and any output difference b, the probability DP(a,b) depends on
the
> > > secret key. We can show that *on average over the key*, this
> > probability
> > > is too low to be useful, which shows that a random linear cipher
> > resists
> > > to differential cryptanalysis.
> >
> > Which is just a different way to resist differential cryptanalysis
> > right?
>
> Different from what?
Well in the function f(x) = a.x + b, there are differential
characteristics that hold with p=1, however they are random chars which
makes the attack hard.
Normally there are known chars with a very small 'p' (probability).
Or am I just out to lunch?
>
> > If you have seen my earlier posts such as TC6a you will see I used
the
> > decorrelated function as my round function. Would you suggest that
as
> > a insecure design?
>
> No I did not.
> I was off recently.
Basically it's a 64-bit 6-round Homgenous Balanced Feistel Network
with "a.x + b" in GF(2)^32 as the round function and addition modulo
2^32 as the feedback function.
There is obviously an impossible differential attack but it requires
much too much work to be practical I would think since the round keys
are 64 bits.
Other then that I am rather sure it's secure against diff/linear
attacks of order 2.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: DH -> 3DES
Date: Thu, 14 Sep 2000 19:26:42 GMT
In article <8pr2pf$8hq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I'm looking for a reference on how to exchange 3DES keys with Diffie
> Helman. What size prime should the DH use to be stronger than 3DES?
> Should I just take the first 24 bytes of the DH computed key as the
> computed 3DES key or is more processing necessary?
> Should I check for weak DES keys?
> Adjust parity?
My suggetion is to use a 1024-bit DH field (1024 bit prime) which has a
large prime factor (i.e p = 2p1 + 1 where p1 is prime). Then hash the
shared value g^xy mod p, to the desired length. If you need a 168 bit
key from SHA-1 you can get the last eight bits via linear mixing of the
first 160 (or hash it again and keep only eight bits). The effective
key length will only be 160 bits but that's plenty long for now.
Otherwise use ElGamal and encrypt a random 168 bit string and don't use
the hash. ElGamal is the variation of DH that allows for signatures
and encryption much like RSA (diff math but similar idea).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
