Cryptography-Digest Digest #453, Volume #9 Fri, 23 Apr 99 07:13:04 EDT
Contents:
MS Win95 PWL files (Georges Gabereau)
Re: 128 bit DES (Gurripato (x=nospam))
TEA rounds (please read) ([EMAIL PROTECTED])
xtea paper (was PGP=NSA) (Paul Rubin)
Re: Adequacy of FIPS-140 ("Trevor Jackson, III")
Re: mcrypt ([EMAIL PROTECTED])
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Bryan G. Olson; CMSC (G))
Re: Symmetric encryption: Secret algorithms?? (wtshaw)
Re: Announce - ScramDisk v2.02h (Matthew Skala)
Re: Question about DH keys? (Matthew Skala)
Re: 128 bit DES (Eric Young)
Re: How robust are pencil and paper cyphers? (DGoncz)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
Re: choosing g in DH (Scott Fluhrer)
Re: xtea paper (was PGP=NSA) ([EMAIL PROTECTED])
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: Georges Gabereau <[EMAIL PROTECTED]>
Subject: MS Win95 PWL files
Date: Thu, 22 Apr 1999 20:44:28 -0400
Hi,
I know about the Glide.exe cracker for the pwl files used for windows
logins, but it only works with Win95 WITHOUT Service Pack 1 installed.
Is there a program that works for Win98 or Win95 with all the patches??
Please reply to email without the .nospam attched.
[EMAIL PROTECTED]
Thanks a lot,
Georges
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: 128 bit DES
Date: Thu, 22 Apr 1999 18:18:00 GMT
On 22 Apr 1999 13:49:00 GMT, "dino" <[EMAIL PROTECTED]> wrote:
>Hi again
>I need some help. My customer ask a crypto application using 128 bit DES. I
>implemented a double DES with two 64 bit keys. Is that equivalent?
>If the answer is negative, is a triple DES with two 64 bit keys equivalent
>to a single 128 bit DES?
>I apologize for my poor english but i hope someone understand my question
>:-)
>thank you
DES is really 56 bits (the other 8 are just for parity
checking). You could combine 2 DES keys, but there´s the chance of a
man-in-the-middle attack. 3 DES has a combined key length of 56*3=168
bits. Even the best cryptanalytical attacks cannot crack it in less
than about 2^112 operations.
------------------------------
From: [EMAIL PROTECTED]
Subject: TEA rounds (please read)
Date: Fri, 23 Apr 1999 03:21:25 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Why doesn't TEA update the sum register after every round?
I think I may update the xtea.pdf paper to include this, as I believe
that would be better!
Any insight?
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0.2i
iQA/AwUBNx/l7PIPgV4W6pz7EQJ9gQCg2MsWa40EBrOzQwN7847JlX9CSkwAn38o
didUUH/zRj73d3HFMCpZLCcl
=cb2C
=====END PGP SIGNATURE=====
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: xtea paper (was PGP=NSA)
Date: Fri, 23 Apr 1999 04:05:23 GMT
In article <7fog5k$jf6$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>>Well I know that much. Not to be picky, but has anyone read my brief
>on extended tea ciphers? I was just wondering. I want to write a
>more professiional paper on it, but I am awaiting feedback. It's in
>PDF format which I think is spiffy.
>
>It's at
>http://members.tripod.com/~tomstdenis/xtea.pdf
First of all, pdf sucks for reading with a web browser.
It's for exercising total control over formatting a document,
usually for printing it. Unless you have a good reason to need
that kind of control, please use html.
Second, as far as getting people to read your paper, it would help
if you posted the main results to the newsgroup, along with the url.
If the paper doesn't contain any significant results, that might
explain why no one is reading and/or responding to it.
I don't mean to be discouraging in any of this; it just seems to me
like these papers (I did look at at least one of the earlier ones)
repeat the classic mistakes of newbie cryptographers. Saying "Try my
new cipher!" is like saying "Try my new elephant repellent!" and when
someone says "but there are no elephants around", answering "see--it
works!!!". The only way anyone to know if your cipher (or repellent)
is any good requires going to the hassle of actually getting an
elephant (i.e. cryptanalyzing the cipher) to test its effectiveness,
and you haven't given reason to believe this is worth the trouble.
So, feedback on your paper: you indicated in your earlier post that
XTEA is secure against some attacks that TEA is vulnerable to. Fine;
revise the paper to drop the part about XTEA, and instead just write
about the attacks on TEA. That is: show that TEA is not a good
elephant repellent, by showing ways that a clever elephant can get
past it.
A paper like that would generate a fair amount of interest, and would
demonstrate that you can tell the difference between good and bad
elephant repellent, which will in turn get your own elephant repellent
formulas taken much more seriously.
------------------------------
Date: Fri, 23 Apr 1999 13:05:07 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Adequacy of FIPS-140
R. Knauer wrote:
>
> On 21 Apr 1999 18:10:39 -0400, [EMAIL PROTECTED] (Leonard R.
> Budney) wrote:
>
> >I would agree that an exhaustive search is not easy. However, text
> >pulled from the web does suffer the same drawbacks as a book code:
> >popular books offer a high probability of success; and human
> >engineering is possible. For example, an ardent Christian is likely
> >to use a Bible, hymnal, or some such.
> >
> >In the case of web documents, lots of human engineering is
> >available. Proxy logs can be reviewed, network traffic (and hence
> >viewing habits) scanned, altavista queries can isolate the few
> >hundreds or thousands of documents reflecting strong interests,
> >hobbies, etc..
>
> You are leaving out some important considerations. You would acquire
> textstreams from diverse random sources, some of which change on a
> daily basis like newsfeeds, and you would obtain the streams by
> offsetting into each text in a random manner. Then you would hash
> these text streams individually and strongly mix them to create the
> keystream.
So, your thesis is that if we have a source of random number to use to
select a text stream and to select a position within the text stream
then we could use the text stream as a source of random numbers.
>
> Doing it in such manner would result in a number of combinations that
> is far too large for an exhaustive search. Just linking to each
> possible text source is impossible in any reasonable time.
If you have an algorithm for deterministicly selecting text streams and
offsets I do not need to exhaust the possible combinations. Only the
one the algorithm selects.
>
> Bob Knauer
>
> European Parliament's Scientific and Technological Options Assessment,
> Appraisal of Technologies of Political Control, including Mark-Free
> Torture, implemented by the British military in Northern Ireland:
> http://jya.com/stoa-atpc.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: mcrypt
Date: Fri, 23 Apr 1999 00:38:10 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
> I don't know what happened to the ftp server. A mirror site
> is http://sg1.math.uoi.gr/~ma06205/mcrypt but it is not always up.
>
> I actually use gzip or bzip2 if they exist in the system.
>
I have GZIP, that FTP site worked. I will try the program out
tonight...
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0.2i
iQA+AwUBNx+/ufIPgV4W6pz7EQKrmwCeP/s0KJQCoBqA1LuJSOmat7HIz9wAlRXC
23PWil/MG4Q8giCnY+z0kIo=
=BCYX
=====END PGP SIGNATURE=====
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Bryan G. Olson; CMSC (G))
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: 23 Apr 1999 05:39:45 GMT
Terry Ritter ([EMAIL PROTECTED]) wrote:
[...]
: It may be unfortunate for academic cryptographers that a wide variety
: of new techniques are pioneered by non-academics. But those
: techniques exist nevertheless, and to the extent that academics do not
: investigate them, those academics are not up with the state of the
: art.
: It is not, frankly, the role of the innovator to educate the
: academics, or even to serve technology to them on a silver platter.
: In the end, academic reputation comes from reality, and the reality is
: that many crypto academics avoid anything new which does not have an
: academic source.
This impression of the academic crypto community as a closed
club that ignores the work of outsiders is flat out false.
Consider power and timing analysis - the entire area came
from the crypto left-field and was pioneered by a recent grad
with a B.A. in biology. The work was good, so now he's one
of those respected cryptologists. The various attacks I've
heard on academics are invariably by those whose work is
simply not of the same caliber.
For an example of an idea the crypto community has ignored
because it is truly dreadful:
[...]
: And in this way we can have hundreds or thousands of different
: ciphers, with more on the way all the time. That means that we can
: divide the worth of our information into many different ciphers, so
: that if any one fails, only a fraction of messages are exposed.
Absurdly naive. In any real project or real enterprise, the
same information is carried by many, many messages. The degree
of protection of any piece of intelligence is that of the
weakest of the systems carrying it.
: It
: also means that *any* Opponent must keep up with new ciphers and
: analyze and possibly break each, then design a program, or build new
: hardware to exploit it. We can make good new ciphers cheaper than
: they can possibly be broken. The result is that our Opponents must
: invest far more to get far less, and this advantage does not depend
: upon the delusion of strength which is all that cryptanalysis can
: provide.
Nonsense. The attacker just waits for the information he wants
to be transmitted under a system he can break.
--Bryan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Symmetric encryption: Secret algorithms??
Date: Fri, 23 Apr 1999 01:44:59 -0600
In article <[EMAIL PROTECTED]>, Peter Gunn
<[EMAIL PROTECTED]> wrote:
>
> Food for thought??
>
Gobble, gobble....Um, Good!
--
Life's battles do not always go to the stronger of faster man...
But, sooner or later always go to the fellow who thinks he can.
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Announce - ScramDisk v2.02h
Date: 22 Apr 1999 20:02:39 -0700
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
>security. If you're going to include code for a number of forms of
>encryption, from a viewpoint of security, you might as well just
>always use ALL the forms of encryption supported, and use the entire
Speed. If you use all the ciphers to encrypt the whole file, it may take
you a very long time. But here's another idea: use some sort of
all-or-nothing scheme, so attackers have to attack the entire file at
once, and then encrypt say the first block with IDEA, the second block
with Blowfish, the third with 3DES, the fourth with SCOTT19U, and so on.
I'm not fully up on how well all-or-nothing schemes work, but it seems
like it should be possible to require the attackers to break all the
ciphers, while still not having to do all the ciphers on all the blocks.
--
Matthew Skala Ansuz BBS (250) 472-3169 http://www.islandnet.com/~mskala/
GOD HATES SPAM
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Question about DH keys?
Date: 22 Apr 1999 20:15:28 -0700
In article <[EMAIL PROTECTED]>, Paul Rubin <[EMAIL PROTECTED]> wrote:
>You're thinking of RSA. Diffie-Hellman doesn't work like that.
>The DH keys are not interchangeable.
RSA keys are not completely interchangeable either, at least not when
generated in the usual way, because given the secret key it's easy to find
the public key. Thus, you can't keep the public key secret, give out the
secret key, and expect the system to be secure. The keys *are*
interchangeable in the sense that E*D = D*E = I where * denotes
composition, in other words you can encrypt first and then decrypt, or
decrypt and then encrypt (the signature algorithm) and either way you get
back to where you started.
Actually, that isn't true either, but it's close enough that the chance of
it failing on any particular message is vanishingly small. If you find an
exception you've broken the key.
--
Matthew Skala Ansuz BBS (250) 472-3169 http://www.islandnet.com/~mskala/
GOD HATES SPAM
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: 128 bit DES
Date: Fri, 23 Apr 1999 20:28:10 +1000
Eric Young wrote:
>
> Steven Alexander wrote:
> > Double DES is unfortunately not considered to be more secure. Using
> > triple-des is considered to be equivalent to having a 112-bit key.
>
> A recent paper "Parallel Collision Search with Cryptanalttic
> Applications'
> (P.C. van Oorschot and M.J. Wiener)
> indicates a new approach to collision searching. The estimation for the
> effort to break two key triple DES is $10m and 4 years or run time given
> two known plain texts. Based on this, their estimation is that two key
> DES gives about 17 more bits security that single DES. I've heard
Woops, this is for double DES, not two key triple DES.
------------------------------
From: [EMAIL PROTECTED] (DGoncz)
Subject: Re: How robust are pencil and paper cyphers?
Date: 23 Apr 1999 10:35:41 GMT
I have a book from Lindsay Publications, a reprint. It's pretty old. But it
discusses pencil and paper ciphers and little else.
Don't know the answer to your question.
Yours,
Doug Goncz
Replikon Research, PO Box 4094, Seven Corners, VA 22044-0094
Please DO copy your reply to me via e-mail.
http://users.aol.com/DGoncz or /ReplikonVA
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Fri, 23 Apr 1999 12:36:21 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > SCOTT19U.ZIP_GUY wrote:
> > >
> >
> > > for a quick not complete explained it is this:
> > > 1) the compressed file ends exactly on a byte boundary and sent as suchh
> > > 2) the compressed file has filler in the last byte.
> > > 3) the compressed file is truncated so last symbol is not fully written
> >
> > I suppose that for files that are to compressed not all 256 symbols
> > of ASCII are used. So one could certainly choose one that is not
> > used as the end-of-file symbol and then fill the last byte with
> > anything, if needed. That would give the receiver the certitude
> > that the file indeed ends and has not been truncated. What is your
> > opinion? (One could use a pair or a triple of symbols as end-of-file,
> > if all 256 symbols are used.)
> >
> > M. K. Shen
> >
>
> 2 Points
> 1) If a file is compressed and then you examin it in terms of
> 8 bits symbols then you would expect all 256 symbols to appear
> since a file this is compressed would hopefully approach that
> of a random file.
You misunderstood me. I mean a file that is to be compressed (normally
an ordinary text file, program source, etc.) with extremely rare
exceptions doesn't use all 256 symbols. So one of the unused
symbols can be specified in the Huffman table to serve as an
end-of-file mark.
> 2) If you use a set of symbols as the end of file in the
> compressed text. It gives tremendous information to an attacker
> if one only looks at the last few blocks and if encrypted with
> the small key AES or DES type of methods one need only try keys
> or recovery methods that examin the last few blocks of encrypted
> text to check for a file with the end of file marks.
> When one finds a match it is very likely the solution to the
> whole encryption. One should never allow for a constant ending
> pattern in the compressed text. One should use compression that
> forces the attacker to least do a full pass of the encrypted text
> before a solution can be ruled out. One should never ever leave
> the kind of hooks that are in products like PGP if one wants real
> security.
There are likely to be many candidates for the symbol that is choosen
as the end-of-file symbol. How is the analyst going to guess that
in the Huffman encoded form? He knows that that must be somewhere
among the last bunch of bits but no more. That doesn't seem to
leek any information to him (moreover that symbol is used only once).
If an encryption is any good, then even using a fullstop to end
sentences is acceptable. I think that providing an end-of-file
does have a programming advantage.
M. K. Shen
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: choosing g in DH
Date: Fri, 23 Apr 1999 10:49:04 GMT
In article <7foqh5$[EMAIL PROTECTED]>,
"Roger Schlafly" <[EMAIL PROTECTED]> wrote:
>
>Michael J. Fromberger wrote in message
><7foilt$5r6$[EMAIL PROTECTED]>...
>>Actually, the value of g should be chosen to be a primitive element
>>(also known as a "generator") modulo p. A value g is a generator
>>modulo p if the smallest value x such that g^x = 1 (mod p) is (p - 1).
>
>No, the earlier advice was better. There are some attacks if g is a
>generator. It is safer to choose g to have prime order.
That makes no sense. If you know a generator g in which you can
compute discrete logs, then you can compute discrete logs in any
base. Here's how:
Suppose that you have a specific prime p and generator g, you can
solve the discrete log problem. That is, for any value a, you
can compute x s.t.:
g^x = a mod p
And, you problem you want to solve is: given h and b, you want to
compute y s.t.:
h^y = b mod p
Then, you proceed by finding z and w s.t.:
g^z = h mod p
g^w = b mod p
Then you compute y s.t.:
y * z = w mod p-1
which is easily solved.
In addition, if you weaken the assumption to that you can
solve the DL problem base g with nontrivial probability,
then there is a way to make this attack work with that as
well. I won't bother people with it unless asked.
--
poncho
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: xtea paper (was PGP=NSA)
Date: Fri, 23 Apr 1999 10:36:01 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Well I agree with you but.... I never said try my
new cipher, I said take a peek. I know better
than that.
You are right, I should have published results,
but I am sorta newer and haven't found any
good resources on learning cryptanalysis.
Maybe I will try your idea. And just explain
how TEA has weaknesses, and how I
would improve it.
Thanks for the feedback.
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0.2i
iQA/AwUBNyBL4/IPgV4W6pz7EQJp5QCfX9/NnbM/flzftESn0v3RprS473gAoLj/
RHJD4a7ESR+pVmE51wmBuxi6
=urp1
=====END PGP SIGNATURE=====
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Fri, 23 Apr 1999 20:13:05 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Mok-Kong Shen wrote:
>
> SCOTT19U.ZIP_GUY wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > > SCOTT19U.ZIP_GUY wrote:
> > > >
> > >
> > > > for a quick not complete explained it is this:
> > > > 1) the compressed file ends exactly on a byte boundary and sent as suchh
> > > > 2) the compressed file has filler in the last byte.
> > > > 3) the compressed file is truncated so last symbol is not fully written
> > >
> > > I suppose that for files that are to compressed not all 256 symbols
> > > of ASCII are used. So one could certainly choose one that is not
> > > used as the end-of-file symbol and then fill the last byte with
> > > anything, if needed. That would give the receiver the certitude
> > > that the file indeed ends and has not been truncated. What is your
> > > opinion? (One could use a pair or a triple of symbols as end-of-file,
> > > if all 256 symbols are used.)
> > >
> > > M. K. Shen
> > >
> >
> > 2 Points
> > 1) If a file is compressed and then you examin it in terms of
> > 8 bits symbols then you would expect all 256 symbols to appear
> > since a file this is compressed would hopefully approach that
> > of a random file.
>
> You misunderstood me. I mean a file that is to be compressed (normally
> an ordinary text file, program source, etc.) with extremely rare
> exceptions doesn't use all 256 symbols. So one of the unused
> symbols can be specified in the Huffman table to serve as an
> end-of-file mark.
>
There is no need to reuse a character symbol. Simply start whatever
frequency analysis woth and extra, 257th, symbol (EOF) with frequency
1/filesize. If you perform no pre-analysis at all, and do not pre-load
a set of frequency statistics (the adaptive case), you'll have a table
of 257 symbols all of the same weight.
> > 2) If you use a set of symbols as the end of file in the
> > compressed text. It gives tremendous information to an attacker
> > if one only looks at the last few blocks and if encrypted with
> > the small key AES or DES type of methods one need only try keys
> > or recovery methods that examin the last few blocks of encrypted
> > text to check for a file with the end of file marks.
> > When one finds a match it is very likely the solution to the
> > whole encryption. One should never allow for a constant ending
> > pattern in the compressed text. One should use compression that
> > forces the attacker to least do a full pass of the encrypted text
> > before a solution can be ruled out. One should never ever leave
> > the kind of hooks that are in products like PGP if one wants real
> > security.
>
> There are likely to be many candidates for the symbol that is choosen
> as the end-of-file symbol. How is the analyst going to guess that
> in the Huffman encoded form? He knows that that must be somewhere
> among the last bunch of bits but no more. That doesn't seem to
> leek any information to him (moreover that symbol is used only once).
> If an encryption is any good, then even using a fullstop to end
> sentences is acceptable. I think that providing an end-of-file
> does have a programming advantage.
>
> M. K. Shen
------------------------------
** 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
******************************
