Cryptography-Digest Digest #736, Volume #10 Tue, 14 Dec 99 01:13:01 EST
Contents:
Re: An attack on the WTLS SHA_XOR_40 MAC algorithm (David Wagner)
Re: SRP - a secure alternative for authentication >> Nice reading ... (Thomas Wu)
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Re: Deciphering without knowing the algorithm? ("Surface Mount")
Re: Deciphering without knowing the algorithm? (Jim Gillogly)
How do you crack a Rotating Grille? (UBCHI2)
Re: Are thermal diodes as RNG's secure ("John E. Kuslich")
Re: The Code Book (Septyn)
Re: Simple newbie crypto algorithmn (SCOTT19U.ZIP_GUY)
Re: Economic Espionage Act of 1996 and the U.S.A. government's violations
(SCOTT19U.ZIP_GUY)
Re: How do you crack a Rotating Grille? (Jim Gillogly)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Security analysis of digitalPersona's U.are.u? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: An attack on the WTLS SHA_XOR_40 MAC algorithm
Date: 13 Dec 1999 19:16:17 -0800
Good catch. Yeah, I agree: the so-called WTLS `XOR MAC' is seriously
flawed, and definitely should be eliminated with all possible haste.
Submitting your result to WAP might be useful, to keep them honest.
Last I heard, they were a semi-secret design committee, and one always
has to wonder about the effects of secrecy & politics on the resulting
standards.
You might also be interested in the following paper:
Markku-Juhani Saarinen, ``Attacks against the WAP WTLS protocol.''
1999 Communications and Multimedia Security conference.
This paper shows some different attacks on the `XOR MAC', and also
describes several other security misfeatures of WTLS.
Finally, here is a third observation on the `XOR MAC', not mentioned in
the above paper or in your post. Take any ciphertext block and replace
it with 10n+1 repetitions of itself, for any n>0; then the MAC will
remain unchanged. This presents yet another easy forgery attack.
For example, modifying ciphertext X Y Z into X (11 Y's) Z will not be
detected by the MAC, if X,Y,Z each represent a single (8-byte) ciphertext
block. This has a very easily predicted effect on the resulting
plaintext: it inserts 10n copies of the plaintext block Decrypt(Y) xor Y.
If you repeat a ciphertext block that corresponds to some known plaintext
block (perhaps because it is part of a predictable TLS header or guessable
HTTP request or somesuch), you can even control the inserted plaintext
block to some extent.
You can also apply similar tricks to any sequence of consecutive
ciphertext blocks, if you like.
You can use this trick to do cut-and-splice attacks, a la Bellovin's
IPSEC work. For instance, suppose we have the ciphertext U V W that we
want to get decrypted for us. We wait until we get ahold of the channel,
perhaps using an echo feature in some application like suggested in
M.-J. Saarinen's paper. Then, when we see ciphertext X Y Z, we modify
it to become X (10 copies of U V W X) Y Z. This attack will not be
detected by the XOR MAC, and it lets us read any traffic we like.
At this point I would claim it should be clear that the `XOR MAC' is
fatally and fundamentally flawed.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: SRP - a secure alternative for authentication >> Nice reading ...
Date: 13 Dec 1999 19:24:07 -0800
"rosi" <[EMAIL PROTECTED]> writes:
> Also, password-based and password-dependent convey slightly different
> meanings. (Personal taste again). As far as SRP is concerned, due to
> the intended (DH) transformation, it gives an uncomfortable feeling to
> view it in the old concept of a password.
That's exactly the point - although the technology has been improved,
from the user's point of view, it's still password authentication. The
only difference is that it can't be broken from the wire. The user
should be unaware that the software is executing an authenticated DH-based
exchange underneath.
> It is implicit that the hash is necessarily:
>
> for all x, y, z, H(x, y, z)=H(H(x, y), z)
No, H(x, y, z) = H(concat(x, y, z)).
> Maybe too obvious, but B = v + g^b should really be B = H(v, s) + g^b?
No. The salt is already used to compute x, which is then used to
compute v.
> Similarly, x being defined as 'A private key derived from the password
> and salt' is not accurate. Let v = H(P, t), then x = H(P, t, s) for
On page 6, x is defined as being H(s, P), which is exactly a private key
derived from the password and salt.
> some (random t) and P being the password. Of course, if we look closely,
> such as going back to page 6, or looking at step 5, the relationship
> between x and v seems confusing.
On page 6 (assuming you have the canonical published paper), v = g^x (mod n).
> One other thing I find interesting is the dividing line between
> encryption and non-encryption. Would it be reduced to a word game or
> is there really something to it? If you can establish secrets securely,
> you should be able to have secrecy WITHOUT encryption (if that means
> using DES and such), am I wrong?
There is a significant difference. SRP causes the same authenticated
secret to materialize on both sides of the connection, without
encryption. "Data confidentiality", which is what the export regs
deal with, involves transporting some value M that one side possesses
to the other party without being intelligible to an eavesdropper, which
SRP does not do.
Then again, with concepts like chaffing/winnowing which show how to
get confidentiality from authentication, there are many gray areas
up for discussion here.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Mon, 13 Dec 1999 22:57:06 -0500
Reply-To: [EMAIL PROTECTED]
Anton Stiglic wrote:
> > No I can't - there are ways to securely make key of any length
> > (from 64 bis to 768*3 bits) for 3DES.
>
> Hunn??? 3DES uses DES, 3 times, with 3 different keys.......
> I would realy be interested in seeing you come up with a 72 bit
> key 3-DES.
If you are "really interested", then go read the paper I gave
the URL for. It was presented at PRAGOCRYPT'96.
[now into insult exchange]
> Do you have any idea of what you are talking about?
Do you have any brains to comprehend what I'm talking about?
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: "Surface Mount" <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Date: Mon, 13 Dec 1999 23:15:01 -0500
If you were to take a common algorithm for encryption, and modify it
significantly, how hard would it be to decipher the message, assuming a good
algorithm?
Arthur Dardia <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Yeah. Just try every single algorithm. Decrypting a message given a key
is
> rather fast. However, a "secret" algorithm cannot be guessed very easily.
>
> HKXLF wrote:
>
> > Hi,
> > I am new to cryptography although I am very interested in the subject.
From
> > browsing though this newgroup, I have come to a conclusion that, in
order to
> > decipher some message, all you need is to find the key. But how about
the
> > algorithm that is used the encrypt the text in the first place. Is it
possible
> > to decrypt some text without first knowing what algorithm is used to
encrypt
> > it?
> >
> > Anyway, I'll be grateful if anybody can satisfy my curiosity.
> > Thanks,
> > Herry.
>
> --
> Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
> PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
>
>
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Date: Tue, 14 Dec 1999 04:34:02 +0000
HKXLF wrote:
> Is it possible
> to decrypt some text without first knowing what algorithm is used to encrypt
> it?
Yes, depending on the class of cipher being used. For example, if
somebody's running an unknown stream cipher with the same offset or
with an insufficient variety of offsets, it may be possible to recover
all the parts that overlap from several messages without ever knowing
the underlying stream cipher involved. This is also a common theme
in classical cryptography; one of the Zendian ciphers types can be
mostly solved without identifying the algorithm this way -- solved
<enough>, anyway -- although if you go the next step and figure out
the actual algorithm you can read more of the traffic.
For modern block ciphers it becomes a non-issue since we don't have
good cryptanalytic attacks on them anyway if they're implemented
correctly in an otherwise secure system. A desideratum for a modern
cipher is that it should be secure even against a great deal of
chosen plaintext, even if the algorithm is known.
--
Jim Gillogly
Highday, 24 Foreyule S.R. 1999, 04:27
12.19.6.14.2, 4 Ik 10 Mac, Third Lord of Night
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: How do you crack a Rotating Grille?
Date: 14 Dec 1999 04:50:28 GMT
If you are given a large board of letters, how do you determine the Grille
openings and rotations?
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Are thermal diodes as RNG's secure
Date: Mon, 13 Dec 1999 15:52:28 -0700
Ahem...
First of all, there is no such thing as a "thermal" diode. All
semiconductor PN junctions are temperature sensitive in a number of ways
and this sensitivity is well characterized by the Ebbers Moll equations
and the Gummel Poon model of a transistor.
The aspect of a diode PN junction that makes it useful as a source of
randomness is that it suffers from a phenomenon known as shot noise.
Shot noise is a characteristic of any process that involves the flow of
quantized material. In the case of diodes, the minority carriers in the
junction (electrons or holes) have a strictly quantized amount of charge
(the charge on an electron is constant) and there is always a finite
number of minority carriers in the junction. The result is that the
flow of carriers (the current) in the junction has a shot noise
component.
There are cetain zener diodes which are sometimes called "noise diodes"
which are particularly noisy and have "excess noise" (more than can be
explained by the shot noise phenomenon) that results from defects at the
junction surface and are associated with unusually large reverse leakage
current. These diodes are sometimes used in RNG's because they require
much less amplification of the diode noise signal.
Amplification and detection are the areas of RNG design where the rubber
meets the road. It is easy to build a really spectacularly bad RNG and
very very difficult to build a cryptographic quality RNG based on
diodes. I offer no proof of this statement here, just massive quantities
of gray hair...Go ahead try it, you'll see :-))
An RNG based on diode noise, or any electronic noise will suffer from an
unbelievable number of environmental sensitivities (including
sensitivity to ambient light when packaged in glass). ...I can recall
chasing down a 120 hz noise problem in a circuit that only appeared in
the presence of flourescent lamps. These lamps do not provide constant
illumination but actually flicker on and off twice for each power line
cycle...
For cryptographic applications, electronic RNG's present a number of
opportunities for the bad guys to exploit. Everything from manipulation
of room temperature to use of microwaves or other EMI to light or
powerline voltage.
Good electronic cryptographic RNG's exist but not one electronics
engineer in ten thousand is capable of designing one.
There exist techniques for distilling random data from a low entropy
source such as a poorly designed diode source, but all of these
techniques reduce the ultimate bit rate of the RNG.
JK
Tom St Denis wrote:
>
> In article <831142$s6l$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Is a termal diode being used as a RNG secure?
> >
> > Is it possible to manipulate the electronics to make the output of the
> > diode not-so-random?
>
> Change the voltage? As I understand it diodes work by letting current
> go thru only when it passes a voltage, but when it equals the voltage
> it let's it pass at 'random'.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: Septyn <[EMAIL PROTECTED]>
Subject: Re: The Code Book
Date: Tue, 14 Dec 1999 05:22:44 GMT
Warner wrote:
>
> The first sentence of Simon Singh's _The Code Book_ is, "On the morning of
> Wednesday, 15 October 1586, Queen Mary entered the crowded courtroom of
> Fotheringhay Castle". The calendars I have referred to give this date as
> being on a Saturday. I'm interested in hearing comments on this apparent
> inconsistency or references to such.
>
> --
The Gregorian calendar was adopted by the Catholic Church and some
countries in 1582, when October 4 was followed by October 15, a 10 day
difference. (To correct for calendar drift relative to the seasons.)
Britain didn't start using the Gregorian calendar until 1752. Wednesday
+ 10 days = Saturday. I'm guessing the calendars you've referred to, or
those Singh referred to, weren't really meant to be used before 1800 or so....
See http://www.holger.oertel.com/greg_en.htm for more details, and also
www.calendarzone.com.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Simple newbie crypto algorithmn
Date: Tue, 14 Dec 1999 06:11:06 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> [EMAIL PROTECTED] (Steven Siew) wrote:
>> >That of course is total bullshit. Anyone with basic C programming skills and
>> >basic high school maths can write a crypto algo that the whole world cannot
>> >crack in less than 1000 years.
>> I think one can only say one can make it stronger and more secure than
> what
>> the phony crypto gods do with there short keyed methods. But to say its
> secure
>> for 1000 years is meaining less since who the hell knows where quantum
>> computers will be able to do in ten years.
>
>My own estimate is that, with sufficient motivation, it would take
>at most a few weeks, using a rather ordinary computer with some
>extraordinary software.
I was commenting as I read. I saw no more than what was above when
I commented on the method. It is usually a mistake to say something
can't be broke in 1000 years and has no meaning. But yes as I went
father in more errors or oversties raised there head.
>
>> > scramble key < originaltext > encryptedtext
>> > unscramble key < encryptedtext > decipheredtext
>> Nice way to handle inputs and outputs.
>
>(1) This is the obvious interface on UNIX systems.
>(2) Unless both the plain and cipher text are *text streams*,
>as opposed to arbitrary binary files, this interface will not
>work on some systems; stdin and stdout are text streams.
>
I was trying to be nice. I have been burned by this same
problen on the PC so I would have used
scramble key originaltext encrypted text
My comment was just saying it was nice to be using
UNIX which gives more flexability at times than
DOS.
>> The heart of your method revolves around this sequencing of the
>> buff fib if the sequence can be proven to really have a period of
>> oder 2^(FIBP-1) for any array fib then you may have something
>> but I am not familar with this type of generator. ...
>
>As you noted, there are flaws in the particular method,
>but I want to add that Fibonacci generators *in general*
>have been thoroughly studied and ways to crack them are
>known. Think about it: Fibonacci sequences have a *lot*
>of mathematical structure; that's not good from the point
>of view of resisting analysis.
However I think he has the correct motivation and is not yet fully
poisned by the status quo. It is good he posted here. He hopefully
can learn something and may be able to shortly write code much
better than the AES crap. I hope he just doesn't shallow the
phony crypto god line like little boy tommy who seems incapable
of learning anything. Tommy has to comment on everything and his
ignorance does nothing but show through.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.politics.org.cia
Subject: Re: Economic Espionage Act of 1996 and the U.S.A. government's violations
Date: Tue, 14 Dec 1999 06:23:05 GMT
In article <[EMAIL PROTECTED]>, "Markku J. Saarelainen"
<[EMAIL PROTECTED]> wrote:
>
>I do believe that the government of the U.S.A. with the assistance of
>its intelligence agencies and commercial agencies have violated my
>private property rights and taken away my intellectual property ("Genie
>Services") by listening secretly my own R&D development and audio
>recordings, when I did my R&D work at my own private property in the
>summer of 1998. I do believe that this is the violation of the Economic
>Espionage Act of 1996 among other laws and regulations. I do believe
>that the U.S.A's intelligence and other agencies are involved in
>counter-intelligence activities only to steal a private person's and/or
>company's intellectual properties. Since early 1990's my experience in
>many international corporations has enabled me to create an
>understanding how the U.S.A.'s individuals and corporations are behaving
>offensively against international business people and their intellectual
>properties.
Well they pay the NSA to do something. Why are you so surprised.
It sounds like you expected them to be honest and open. That is not
the way. If you have developed something new get it to market quick
before they give it to another company. You should grow up and
realize they don't follow the laws of the country and the Bill of Rights
is nothing but a minor inconvenecne to them.
>
>I have informed many Ambassadors and other diplomatic people about this
>matter.
>
They can't be very high level diplomats and not already know how
the game is really played. My question is why are you telling us this.
What did they steal and what are you planning to do about it besides
complain to people here. Most people in this group either don't care
or don't belive you since you offer no proof. If you have something
to add about your experiences in advancing crypto please let us
know since I for one am curious what ideas of yours they think
is worth stealing.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: How do you crack a Rotating Grille?
Date: Tue, 14 Dec 1999 05:34:58 +0000
UBCHI2 wrote:
> If you are given a large board of letters, how do you determine the Grille
> openings and rotations?
The traditional method is with a crib -- place the crib by finding places
where the letters will fit at reasonable distances in order, and see what
results two turns along: those same holes will also be in order when the
grille is 180 degrees away from where it started. You may need to try
it in several places before the 180-degree rotation gives good plaintext.
Then fill in the ones at the 90 and 270 degree rotations from your crib,
and try to develop more plaintext to insert in the other rotations. If
there are Q's, look for U's near them, and so on... the usual suspects.
Depending on how large your square is, shotgun hillclimbing is quite
effective -- that's the first cipher I tried it on. It works in reasonable
time up to about 12x12 on a low-powered machine with or without a crib.
I imagine a heavy-duty desktop or more time would take you a little further.
--
Jim Gillogly
Highday, 24 Foreyule S.R. 1999, 05:29
12.19.6.14.2, 4 Ik 10 Mac, Third Lord of Night
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 06:31:47 GMT
In article <fhh54.648$[EMAIL PROTECTED]>, "karl malbrain"
<[EMAIL PROTECTED]> wrote:
>
>Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> "SCOTT19U.ZIP_GUY" wrote:
>> > 1. Depending on how one combines the cipher to make 3DES it could be
>come
>> > to hard for current NSA to quickly decode the message for law
>enforcement.
>>
>> I think you mean FBI. It is explicitly against the law for NSA to
>> intercept communications for the purpose of domestic law enforcement,
>> unless one or more of the communicants are foreign. And, before you
>> say that NSA just ignores the law, that's not so -- this requirement
>> has an effect on how operations are conducted, which wouldn't be
>> necessary if the law were being ignored.
>
>This is an example of VULGAR MATERIALISM. Yes, it's true, that ANY
>measurable operations-effect means that the law is not being ignored, per
>se. That's hardly the point, however. Karl M
>
No I meant the NSA. The FBI does not contain the high caliber of
quality people to break simple codes. That is what the NSA does.
But they don't give a FUCK about the law and your being foolish to
think otherwise. However they don't go out of there way to give evidence
of there law breaking to just every one or people might get pissed and
the government might cut there budget. And just what is
VULGAR MATERIALISM I may be vulgar but I'm not to
materialistic.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
Subject: Security analysis of digitalPersona's U.are.u?
From: [EMAIL PROTECTED]
Date: Tue, 14 Dec 99 05:57:02 GMT
I just received one of these cute little buggers as a Christmas present. The
deluxe version (which sells for the same price as the standard verions--go
figure) includes a secure pseudo-disk utility.
Has anyone published any analysis of this product's encryption method(s) and
possible strength?
MMB
------------------------------
** 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
******************************
