Cryptography-Digest Digest #838, Volume #9 Wed, 7 Jul 99 08:13:03 EDT
Contents:
Re: Kryptos is cracked ("Douglas A. Gwyn")
Re: extending a hash (wtshaw)
CIA'KRYPTOS is cracked ("collomb")
Re: Weak padding ? in message signature (Francois Grieu)
Re: Keeping File Formats Safe (Ronald Klazar)
Re: DES-NULL attack (Thomas Pornin)
Re: Keeping File Formats Safe (Francois Grieu)
Re: I don't trust my sysadmin (Paul Rubin)
Re: Summary of 2 threads on legal ways of exporting strong crypto (Bo D�mstedt)
Re: MP3 Security Requirements? (Francois Grieu)
Crack of CIA'KRYPTOS N3 ("collomb")
Re: Keeping File Formats Safe (fungus)
Re: Windows PWL Files (Torbjorn Lindgren)
Re: Summary of 2 threads on legal ways of exporting strong crypto (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kryptos is cracked
Date: Wed, 07 Jul 1999 06:06:06 GMT
collomb wrote:
> One drawing laid out in the form of the word : <GOD> disposed
> diagonally, ...
Such accidental patterns can be found in any large text; they
don't signify anything (because they *are* accidents).
> See also at : http://calvaweb.calvacom.fr/collomb/
I couldn't get anything past that page to download.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: extending a hash
Date: Wed, 07 Jul 1999 01:20:00 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Is this a good idea to extend a sha-1 hash to 320 bits:
>
> 1st 160 bits=sha(even bytes of plaintext) ^ sha(all plaintext)
> 2nd 160 bits=sha(odd bytes of plaintext) ^ sha(all plaintext)
>
> Is the entropy 320 bits?
You can never get more information out of something than you put in. A
hash result may be in a different form than input, even made to look
longer, but still never represents more than what you started with.
Making something longer by one method or another can be a most useful
process, especially if shorter inputs are expected than are really needed;
it's probably to much to force the little darlin's out there to go for
appropriate sized keys, for instance.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: "collomb" <[EMAIL PROTECTED]>
Subject: CIA'KRYPTOS is cracked
Date: 7 Jul 1999 06:52:09 GMT
Hello
Message Number 2
Glimpses into the decyphering of Krystos
CRACK OF CIA'KRYPTOS
Yesterday 5 july 1999�: GOD disposed diagonally
Today�:
The decyphering makes appear the image of the Cross
See also at�: http://calvaweb.calvacom.fr/collomb/
Best regards
Collomb-Chabrery
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Weak padding ? in message signature
Date: Wed, 07 Jul 1999 09:07:39 +0200
Jean-Jacques Quisquater <[EMAIL PROTECTED]> wrote :
> we select the smooth messages amongst these Mi's (..then..)
> the only computations we need is factorization of these
> messages by the prime numbers less than one million and
> a Gaussian elimination for a matrix 50,000*50,000
I think I now understand the attack you kindly explained:
- select a (big enough) factor base of small primes Pj
and set of Mi that factor as product of Pj^Eij
- choose a forged message M that factors over the Pj, and
by gaussian elimination build a vector of integers Ki
such that product of Pj^(Ki*Eij mod 3) = M
and sum of Ki = 1 mod 3
- it follows that product of (Mi*B)^Ki = M * B * K^3
where K is known as an explicit product of the Pj and B
[B is the multiplicative constant used during signature]
- compute a forged signature of M as
S = (product of Si^Ki) * K^-1 mod N
which verifies S^3 mod N = M*B
This attack becomes practical when there is a set of many
small messages, so one could raise the lower limit for M.
I wonder if the attack could be extended to any linear
padding scheme, e.g. S = (M*B+A)^D mod N
Francois Grieu
Summary of original problem:
- RSA public modulus N with 0 < N-2^n < 2^(3*n/4)
- RSA public exponent E=3, secret key D
- n even, for example 512 (giving N of 513 bits)
- m messages Mi with 2^(n/4) <= Mi < 2^(n/2)
- messages about linearly choosen by authority, we may
assume Mi = M0 + i*2^k for some k<n, maybe k=0
- signature: Si = (Mi*B)^D mod N with B = 1+2^(n/2)
- check: S^E mod N = M*B with 2^(n/4) <= M < 2^(n/2)
------------------------------
From: Ronald Klazar <[EMAIL PROTECTED]>
Subject: Re: Keeping File Formats Safe
Date: Wed, 07 Jul 1999 10:11:33 +0200
William Tanksley wrote:
>
> So, are you fighting cheaters or bandits?
>
The case would be bandits.
My system consists of an editor and a reader. The editor produces a script
that the reader will follow in order to perform certain functions. I do not
want people to uncover the format of the data files from the editor too
easily, thereby providing their own readers and undermining the whole system.
I read somewhere that Autodesk's AutoCAD file format (*.dwg) has not been
easy to reverse engineer. Did they encrypt the file or merely compress it?
Ronald..
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: DES-NULL attack
Date: 7 Jul 1999 07:48:11 GMT
According to Xcott Craver <[EMAIL PROTECTED]>:
> 4 Gigabytes is 2^32 bytes. That's more like 2^29 keys
Oops, sorry, I really should go to sleep sometimes.
> You'd need 128 million tapes
I have one such tape just in front of me. As far as I can estimate, its
dimensions are (in centimeters) 8 x 5 x 1. I suppose I need three times
as much volume for the room, in order to keep some sort of access. This
leads to a 40 x 40 x 10 meters room. A small building.
As for the time to produce the tapes: it is too early in the morning for
me to think about it.
Anyway, this is just all hypothetic.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Keeping File Formats Safe
Date: Wed, 07 Jul 1999 12:08:02 +0200
Ronald Klazar <[EMAIL PROTECTED]> wrote :
> I would like to prevent other people from discovering the format of the
> data files for my application.
> Both the application and data file are stored locally.
If your opponents can reverse-engineer your program, your are in principle
in a loosing position. You can only increase their work.
A possible solution of this well-known dillema is to run your application
in a secure environement, that encrypts your data file. A Java enabled
Smart Card comes to mind : it can contain the key to decipher then
reencipher your data, stored externaly but ran and processed securely
inside the Smart Card. Even your code can be stored enciphered outside
the smart card, and deciphered (and verified) prior to internal execution.
When I had this idea, my company attempted to patent it.
Only to find others have already had it quite some time ago.
Francois Grieu
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: I don't trust my sysadmin
Date: 07 Jul 1999 04:02:50 -0700
"David N. Murray" <[EMAIL PROTECTED]> writes:
> I'm in search of a protocol to implement the following scenario:
>
> I have an automated task that connects to a database.
> The database requires a username/password combination.
> I need to store the username/password with the automated task.
> My system administrator (who needs to be able to read the
> automated task to do backups) is not authorized to access
> the database. (Protecting the database is not my concern.
> Just protecting the automated login.)
>
> How do I store the uname/password to make it as difficult as
> possible for the sysadmin to retrieve? My basic assumption
> is that if I encrypt the password, I have to decrypt it to
> present it to the DBMS. That means that the key, algorithm,
> and ciphertext are all in the same place, right? Isn't that
> a Bad Thing?
First of all, assuming it's a remote database, you can't use a
username/password to log in, because the sysadmin can just sniff
them off the network connection between the application and the db.
You have to replace the password with a challenge/response protocol.
At that point, the simplest approach is to encapsulate the secret key
for the challenge/response in a secure hardware module attached to the
machine running the application. The module would authenticate access
to the database. I assume the database end has enough auditing that
bogus use of the module can be detected, or there's some other way of
distinguishing your task's queries from illicit ones. If you use a
good module, the sysadmin would have to mount a destructive and very
expensive attack to get the key from the hardware, so you can consider
the module as being tamperproof in most any practical situation.
I can suggest particular hardware and so forth by email, if you want.
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Reply-To: [EMAIL PROTECTED]
Date: Wed, 07 Jul 1999 10:20:18 GMT
[EMAIL PROTECTED] (Isaac) wrote:
>English text on paper is exportable. No 'open' encoding required.
>This means print outs of source code can be hand carried or mailed
>overseas while electronic transmission of the exact same material
>without an export license is illegal.
/.../
Referring to that the PGP people had severe problems scanning the
resulting pile of paper, I have a software that encodes the input
before printing, that will make your life much easier.
Bo D�mstedt
Protego Information AB
www.protego.se
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: MP3 Security Requirements?
Date: Wed, 07 Jul 1999 12:22:34 +0200
[EMAIL PROTECTED] wrote, at the end of an interesting post:
> Watermarking of MP3 recorded music is kind of useless.
Can you explain why you think this ? I feel it could be usefull
to watermark the music with the ID of the rightfull owner(s)
of rights and the person the song was sold to, so that
- it's harder for producer X to illegaly resell a song owned by
producer Y, and the customer has a way to detect this.
- customer A runs a risk of identification if he/she illegaly
shares the music file he/she bought with friends/customers.
Francois Grieu
------------------------------
From: "collomb" <[EMAIL PROTECTED]>
Subject: Crack of CIA'KRYPTOS N3
Date: 7 Jul 1999 11:31:30 GMT
Hello
Message Number 3
Glimpses into the decyphering of Kryptos
CRACK OF CIA ' KRYPTOS
5 july 1999�: GOD disposed diagonally
Yesterday : The decyphering makes appear the image of the Cross
Today�: The decyphering makes appear the image of a long snake
See also at�: http://calvaweb.calvacom.fr/collomb/
Best regards
Collomb-Chabrery
[EMAIL PROTECTED]
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Keeping File Formats Safe
Date: Wed, 07 Jul 1999 10:21:59 -0100
Ronald Klazar wrote:
>
> I read somewhere that Autodesk's AutoCAD file format (*.dwg) has
> not been easy to reverse engineer. Did they encrypt the file or
> merely compress it?
>
Their .dxf file format is pretty hard to decipher as well...even
with the docs on hand.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
Subject: Re: Windows PWL Files
From: [EMAIL PROTECTED] (Torbjorn Lindgren)
Date: Wed, 07 Jul 1999 11:53:00 GMT
fungus <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> They proably use their MD4 hash code (which goes with their RC4 code)
>> to hash the password.
>
>Nope.
>
>The files can be decoded in seconds so it isn't a hash.
It's actually RC4, so the guess isn't *that* bad... It's just that
Microsoft totally botched the implementation in the original Win95, so
you could extract the password without even touching the encryption!
Any stream chiper, regardless of strength, would have been equally
vulnerable when used that way!
There were a stand-alone patch for this, then it was included in
SP1. Win95B and Win98 has the fix from the start. I *think* I remember
something about Microsoft increasing the strength of the RC4 crypto
too, from 32! to 128?
After all, the author of the "Glide" did some successful brute force
attacks first, to find out more about how the PWL files were built,
before finding out how to attack them without even touching the
encryption... (Ref: Original posting to Cyberpunks by Frank Stevenson)
>> If you want to cheat a passwd protected screen saver just delete
>> the .PWL files...
>
>And how do you do that if the machine is askign you for a password?
Using the reset or power button :-)
Besides, given that kind of situation you can't access the PWL file on
that machine either, to run Glide on them... Unless they are available
on some other machines, you need to reboot either way.
--
--
Torbj�rn Lindgren
Network Manager, FairPlay International AS
E-mail: [EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: Wed, 07 Jul 1999 14:12:52 +0200
William Tanksley wrote:
>
> On Tue, 06 Jul 1999 12:29:36 +0200, Mok-Kong Shen wrote:
> >Isaac wrote:
>
> >> What you hope to accomplish in your transform appears to be
> >> hiding illegal activity rather than accomplishing a legal
> >> transaction. I find speculation on whether you'll get caught
> >> uninteresting.
>
> >I said that there is NO hiding.
>
> You spoke falsely, then.
I don't understand what you wrote. I wrote previously that Boris
Kazak's method is an 'open' encoding of bits into the English text,
that is, one is not 'secretly' doing that job. Anyone can read out the
coded information, just as if one had written 011010 and the like.
Hence there is NO hiding. Would you please elaborate and explain the
meaning of your sentence?
>
> >Everyone knows that (in all likelihood)
> >lower case means 0 and upper case means 1. It is an attempt to
> >'openly' confront the bureaucrats, who have to offer anyway reasons
> >as to why apparently arbitrarily using lower and upper case to write
> >English text is against laws.
>
> That's utterly trivial -- why are apperently arbitrary sequences of zeroes
> and ones against the law?
>
> Answer: "mu". The question is invalid because neither sequence is in the
> least arbitrary. Exporting arbitrary sequences isn't illegal (although I
> suspect that exporting truly random sequences might be ;-), so long as
> you don't violate the law.
What is the exact meaning of 'Exporting arbitrary sequences isn't
illegal, so long as you don't violate the law'?? Could you elaborate,
perhaps with an example? It sounds to me like 'Exporting something
that doesn't violate the law isn't illegal', which is a tautology.
I suppose you (and some other discussion partners) claim that because
a sentence is not written normally (with upper case at the beginning
and lower case elsewhere excepting the first letter of proper names),
it doesn't pass as a normal sentence by the court. I can't exclude
that. But I believe that there is a pretty good chance that it can't
be shown formally and rigorously that employing upper and lower case
letters arbitrarily is against certain existing laws. Maybe a new
paragraph in the law book is needed. (There is certainly nothing
against one's writing English all in upper case or all in lower case,
isn't it?) I should also point out that Boris Kazak suggested his
method after I posted an approach which is the following: One takes
a widely available book and choose 256 consecutive sentences to
be numbered 0-255 and code each byte of one's information to be
transmitted with the correspondingly numbered sentence. This original
approach of mine doesn't have any problem with lower/upper case. Each
encoded sentence is an 'entirely' normally written English sentence.
The only disadvantage is that the encoded file will be much larger
than the file obtained with Boris Kazak's method. Should it turns out
that Boris Kazak's method cannot get around the crypto regualtions on
grounds mentioned above, then my original approach can be applied.
The encoded file will have numerous repetitions of the same sentences.
But can the authority forbid that? (Can the authority prescribe what
style of writing I must use? Does any law forbid that I repeatedly
say one and the same thing many many times? What if the book I use
is a religious one? Can an authority forbid my repeated citation
of the same sentences from a holy book?) As I already mentioned,
the second scheme is much more inconvenient than the first. The first
(which is certainly o.k.) should be preferred, if possible, in
practice. But the second scheme, even if not employed in practice,
appears to be at least quite useful for attempting to pursuade the
authority that crypto regulations cannot be effectively carried out
and that these therefore should be abandoned.
>
> >> I sincerely hope no one follows any advice from your 'summary'. It
> >> doesn't appear to reflect anything I've seen posted in this newsgroup.
>
> >You have discussed the second scheme, but not the first. The first
> >is certainly o.k. and also convenient, provided one can obtain
> >assistance from a foreign server. On another internet list there
> >has already been one person outside US who voluntarily offers
> >possibilities of storing the relevant stuffs on his server. This
> >clearly shows that web publication of strong crypto, which is at the
> >heart of the Bernstein case, is practical today.
>
> If you export the stuff on paper (i.e. not in machine-readable form),
> you're fine. This has been tested on PGP and a couple of other things.
> Counterpane's web site has a link to an "international" implementation of
> Twofish.
The central purpose is to achieve exporting one's OWN intellectual
proterties via internet, which has been exactly the issue involved
in the Bernstein case. The PGP type of export is not exactly enough
in the present context in my view, because the material exported is
managed (under direct control and rendered public) by a foreigner.
Counterpane's link in my understanding is also to 'foreign' material.
What I described in the first scheme is essentially the following:
One puts the codes, which one couldn't directly place on the domestic
server because of crypto regulations, on a foreign server and gives
the references to these at the places where the codes would have been
if there were no crypto regulations. This ensures much flexibility
for the author. For normally the text part of a paper on the Web is
likely to be updated with time. (This can presumably be the case e.g.
with Bernsteins's lecture notes on cryptography.) If there is no
change in the codes, the author can simply modify his HTML file at
his own place without much ado. Of course, on the other hand, there
is no very 'sharp' line of distinction between the first scheme I
described and what you pointed out above. To use a word that you
employed further above, the matter is 'utterly trivial'. As it turns
out, however, 'utterly trivial' things are not alway familiar to
every one, otherwise the export of strong crypto via internet would
have been a non-issue from the very beginning. (Trivial or non-trivial
is often relative, I suppose. Just think of the problems of geometry
that one solves in schools; all are trivial after one has solved them
but not before. Another example is the tricks the magicians employ.)
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
******************************
