Cryptography-Digest Digest #139, Volume #10 Mon, 30 Aug 99 11:13:02 EDT
Contents:
Re: Can I export software that uses encryption as copy protection? (Eric Lee Green)
Re: WT Shaw temporarily sidelined (Eric Lee Green)
Re: Excerpts from the EAR & BXA Regs regarding Encryption Software (Eric Lee Green)
multicast encryption ("Alex")
Re: What if RSA / factoring really breaks? (Gergo Barany)
Chosen messages attack on ISO 9796-1 signatures (Francois Grieu)
Re: multicast encryption ("Hugh Kennedy")
Re: What if RSA / factoring really breaks?
Re: On employing message-decoys ([EMAIL PROTECTED])
Re: Will CIA be an actor of end-times ? ([EMAIL PROTECTED])
public key encryption - unlicensed algorithm ("shivers")
Re: NEW THREAD on compression (SCOTT19U.ZIP_GUY)
Re: WT Shaw temporarily sidelined (SCOTT19U.ZIP_GUY)
Workshop in Paris on Watermarking and Copyright enforcement (Louis Granboulan)
Re: Key Establishment Protocols - free chapter from Handbook of Applied (Anton
Stiglic)
----------------------------------------------------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Can I export software that uses encryption as copy protection?
Date: Mon, 30 Aug 1999 00:19:40 -0700
Timur Tabi wrote:
> Do you have a reference for that statement? I'm trying to find where in the
> law it says I can do that. I need hard proof before I can go ahead with it.
Basically, if it does not decrypt or encrypt generic files on disk or
data streams flowing over a network, it's not really qualified as
encryption. I'd still submit it to the Commerce dept. for export
approval though.
I'll just point out that encrypting license key files is pretty
pathetic, since MD5 or some other similar message digest gives you the
same level of security (i.e., you have a secret key embedded somewhere
in your program, the license key file includes an MD5 digest, you MD5
the file along with your secret and if it does not match the embedded
digest then they've fiddled with the license key and you are "BAD"). The
only thing that encrypting the license key file gives you that MD5'ing
it doesn't is that you cannot view the contents of the license key file
with an ASCII text editor if it's encrypted. To me, that's a
disadvantage, since it makes your license generator harder to debug.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: WT Shaw temporarily sidelined
Date: Mon, 30 Aug 1999 00:14:36 -0700
"SCOTT19U.ZIP_GUY" wrote:
> In article <[EMAIL PROTECTED]>, Jim Dunnett wrote:
> >On Sat, 28 Aug 1999 19:57:15 GMT, [EMAIL PROTECTED] (don garrisan) wrote:
> >>Bill has asked me to let you guys know that he will be off line for a
> >>short while. Currently in the hospital, he will be back in touch with
> >>the group as physical progress, time and laptop make it possible.
> >
> >Please convey my best wishes for a speedy recovery to him.
> >
> Which hospital is he in. maybe I can drop by and cheer him up.
C'mon now, Scott, you don't want him to die from busting all his
stitches laughing, do you? (grin).
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Excerpts from the EAR & BXA Regs regarding Encryption Software
Date: Mon, 30 Aug 1999 00:32:45 -0700
Anthony Stephen Szopa wrote:
>
> The most significant Excerpts from the EAR & BXA Regs I found.
Interesting. 744.9 (prohibiting me from giving technical assistance to a
foreign firm working on encryption products) appears to be a clear
infringement upon my free speech rights as guaranteed by the 1st
Amendement of the United States of America. I do not have the right to
shout fire in a crowded theatre, but I definitely have the right to talk
about fire all I want with whoever I want (unless I signed away that
right by, e.g., accepting a security clearance). Of course, with both
the Democrats and Republicans treating the Constitution like so much
toilet paper, I'm not surprised that they have issued such a ridiculous
regulation.
Followups to talk.politics.crypto.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: "Alex" <[EMAIL PROTECTED]>
Subject: multicast encryption
Date: Mon, 30 Aug 1999 11:18:05 +0200
Hi people,
I need to encrypt an IP stream that have to be received by several end user.
Is it possible to use a symmetric algorithm like IDEA ?
In this case have all the users the same key ?
thanks to everybody
Alex
------------------------------
From: [EMAIL PROTECTED] (Gergo Barany)
Crossposted-To: alt.math,sci.math
Subject: Re: What if RSA / factoring really breaks?
Date: 30 Aug 1999 09:56:37 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>From "David J Whalen-Robinson" <[EMAIL PROTECTED]>:
>
>
>> Combining generators may be great if done carefully, but what method do you
>> recommend
>> for public key encryption?
>
>We don't recommend public key encryption at all because public key
>encryption can now be
>broken in real time with Bill Payne's recent advances in factoring.
Can you point us to a document that describes Bill Payne's factoring
method?
Gergo
--
Klein bottle for rent -- inquire within.
GU d- s:+ a--- C++>$ UL+++ P>++ L+++ E>++ W+ N++ o? K- w--- !O !M !V
PS+ PE+ Y+ PGP+ t* 5+ X- R>+ tv++ b+>+++ DI+ D+ G>++ e* h! !r !y+
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Chosen messages attack on ISO 9796-1 signatures
Date: Mon, 30 Aug 1999 13:00:19 +0200
This announces a chosen messages attack against ISO/IEC 9796-1.
ISO/IEC 9796-1 is an international standard defining a digital signature
scheme giving message recovery [1]. It adds redundancy to a message before
applying an RSA or Rabin cryptosystem, as a protection against several
potential threats [2].
For odd public exponents, the new attack constructs sets of 4 messages such
that the signature of any one message can be derived from the signature of
the 3 others, and the public key. Bigger sets can be constructed, allowing k
forgeries from k+2 signatures. For a given modulus size, the same messages
work for any modulus and any odd exponent. The attack is computationally
inexpensive. It is not an attack on the RSA or Rabin cryptosystems.
The method is quite different from the forgery strategy on a 1-bit variant of
ISO/IEC 9796-1 disclosed by Coron, Naccache and Stern in [3], although their
paper gave the motivation to work on an attack against full ISO/IEC 9796-1.
The attack is likely to be a threat only to systems that use ISO/IEC 9796-1
in ways that allow an attacker to obtain signatures of mostly chosen
messages. It is urged to quickly revise such systems.
The method will be explained in a forthcoming paper released not before
October 1, 1999. In the meantime, examples and preliminary versions of the
paper will be privately circulated for review (giving an example here would
reveal the attack without prior notice, which could be viewed as hostile).
As a cheap timestamping, here is the SHA1 hash of a witness file with example
messages for 1024 bit keys: 117AA5EFE71474809FB21C75E0D5F766E4E5B083
Francois Grieu <[EMAIL PROTECTED]>
Technical director, Innovatron.
1, rue Danton - 75006 Paris, France.
References:
[1] ISO/IEC 9796-1:1998, "Information technology - Security techniques - Digital
signature scheme giving message recovery � Part 1: Mechanisms using redundancy"
[2] Louis Guillou and Jean-Jacques Quisquater, "Precautions taken against
various potential attacks in ISO/IEC DIS 9796", Advances in Cryptology -
EuroCrypt '90, Springer-Verlag.
[3] Jean-Sebastien Coron, David Naccache, and Julien P. Stern, "A New Signature
Forgery Strategy applicable to ISO-9796-1/2, ECash(tm), PKCS#1 V2.0, ANSI X9.31,
SSL-3.02", to appear; preliminary version circulated as ISO/IEC JTC1/SC27 N2329.
[4] Robert D. Silverman and David Naccache, "Recent Results on Signature
Forgery", <http://www.rsa.com/rsalabs/html/sigforge.html>
[5] Louis Guillou, "Report of the SC27/WG2 ad hoc meeting in Paris, France,
May 14, 1999 on Signature forgery attacks", circulated as ISO/IEC
JTC1/SC27 N2355.
[6] Don Coppersmith, Shai Halevi, Charanjit Jutla, "Some countermeasures against
the new forgery strategy", circulated as ISO/IEC JTC1/SC27 N2362.
------------------------------
From: "Hugh Kennedy" <[EMAIL PROTECTED]>
Subject: Re: multicast encryption
Date: Mon, 30 Aug 1999 11:57:16 +0200
Your scheme should work but unless you have reliable multicasting, you need
to encrypt each block separately (no chaining). If the reliability is
implemented below the encryption layer, then no problems.
Hugh.
Alex <[EMAIL PROTECTED]> wrote in message
news:7qdi21$flf$[EMAIL PROTECTED]...
> Hi people,
> I need to encrypt an IP stream that have to be received by several end
user.
> Is it possible to use a symmetric algorithm like IDEA ?
> In this case have all the users the same key ?
> thanks to everybody
>
> Alex
>
>
>
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: alt.math,sci.math
Subject: Re: What if RSA / factoring really breaks?
Date: 30 Aug 99 13:00:04 GMT
Nicolas Bray ([EMAIL PROTECTED]) wrote:
: How so? It seems to me that there are a lot of institutions which would
: require time to switch over to a new crypto system. It seems to me that
: the best way would be demonstration that a method exists followed by total
: secrecy(of course, a lot of people would probably start trying to kill
: you...)
Actually, it doesn't take much time to temporarily suspend accepting
credit card orders over the Internet.
And there's always the chance one is killed after being tortured for the
secret by someone planning to make a brief criminal use of it.
Also, a demonstration that cannot be reproduced is not very convincing.
John Savard
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On employing message-decoys
Date: Mon, 30 Aug 1999 13:14:50 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> On the assumption that absolute security is neither attainable nor
> (often) necessary/affordable, that no adversary is omnipotent (having
> infinite resources) and that no real-life message needs to be kept
> secret till eternity, let's consider the following scenario:
>
> Alice wants to send a message to Bob. The content of the message
> needs to be kept secret only within 24 hours (e.g. stuffs concerning
> decision making in commercial negotiations) and estimates that
> this time frame is just within the capability of the adversary. She
> sends in addition to the true message 9 dummy messages with random
> or bogous contents, employing different keys. Doesn't this increases
> the security of her message tenfold because the chance of analysis
> is reduced to 1/10 of the original? If she sends 99 dummy messages,
> doesn't she have a legitimate hope that the adversary would probably
> give up?
Well, this brings up a problem.
1. How does Bob know which message is correct? There needs to be a way
for Bob to know what the correct message is without it being to obvious.
Beginning a message with "Hey Bob, this is the right one!" is not very
effective.
If you can encrypt with different algorithms, you could try something
like this.
1. Alice and Bob agree on an encryption algorithm beforehand in a secure
method (she whispers in his ear, for example)
2. Now, when Alice sends a message, she encrypts the correct message
using the agreed upon algorithm and several dummy messages with other
algorithms. (Different algorithm per message if possible)
3. When Bob recieves the messages, he decrypts them until he finds one
that decrypts correctly. That would be the real message.
Now, some of you may be thinking that you would get the same results by
using different keys for each message. Well, what if you use random
session keys? This way the same key, or random keys, can be used for
each message, but the attacker still has to determine which algorithm
encrypted which message. Basically this becomes a real pain in the ass.
I don't know off the top of my head if this scheme would require each
algorithm to be "secure", but I think that it would be a pain either
way. Of course, one may theorize that the message encrypted with 40-bit
DES may not be the real message.
>
> I believe that employing message-decoys is a fairly valuable means
> of achieving enhanced information security in practice, since higher
> message transmission cost is nowadays barely a matter of concern for
> materials requiring some nontrivial protections. Certainly the scheme
> can be subsumed by what has long been known in cryptology as the
> 'busy channel'. But I think that this special case probably does
> deserve our mentioning separately to the common users of encryption
> algorithms.
>
> M. K. Shen
> -------------------------
> http://home.t-online.de/home/mok-kong.shen (new addr.)
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Will CIA be an actor of end-times ?
Date: Mon, 30 Aug 1999 14:11:59 GMT
In article <01bef24b$850ad060$0c150f9a@collomb>,
"collomb" <[EMAIL PROTECTED]> wrote:
> At july 20, 1999, a certain [EMAIL PROTECTED] wrote on this
> newsgroup
> sci.crypt�:
> <Congratulations, I think you actually have cracked it! Your whole
> explanation makes perfect sense.>
> Mario Lyken disappeared, his e-mail address is erroneous and his
> contribution
> faded away from www.deja.com
> Do you know Mario Lyken�?
Just as a hint, the 'anagrams.r.us' domain might be a clue that the
username 'markio.lyken' is actually an anagram for some other phrase
that pertains to how that person chooses his encryption keys, as
opposed to your 'method'.. (Or, perhaps, that he's an insincere
simian..)
It may also be a clue that his response was not entirely without
sarcasm.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "shivers" <[EMAIL PROTECTED]>
Subject: public key encryption - unlicensed algorithm
Date: Mon, 30 Aug 1999 15:16:00 +0100
I could really use a decent (i.e. strong) public key encryption algorithm
that is unlicensed for commercial use - I am interested in Blowfish/Twofish
for a private key algorithm - but my requirements really need a public key
one.
Is there any such algorithm about?
Also, on the legal side - I hear is is legal to export the details on a
strong algorithm - but not an actual implementation of it? If this is
true - and I write an implementation of a strong algorithm - what am I
allowed (and not allowed) to do with it?
(please email a reply as well as posting here)
Thanx a lot,
Shane Wright
ProActive Computing
Email:
work: [EMAIL PROTECTED]
home: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NEW THREAD on compression
Date: Mon, 30 Aug 1999 14:35:45 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>
>> >On the other hand, on the assumption that a certain small defect
>> >to be described below is acceptable, I like to propose the following
>> >modification of my scheme:
>> >
>> >(1) Encode with the normal Huffman algorithm.
>> >
>> >(2) If the last bit output is not at byte boundary (or word boundary,
>> > if output is to be in whole words), fill with 0's to byte/word
>> > boundary.
>> >
>> >(3) Delete trailing zero bytes/words.
>> >
>> >(4) On decompressing, if the buffer is not empty at end of file,
>> > append as many 0's as are necessary to form a valid Huffman
>> > code.
>> >
>> >This evidently suffices to achieve Scott's 'one to one' property
>
>> It obviously does not fill the "one to one" requirement
>> since as you point out it may have spurious symbols at the
>> end of file. But it does allow every file to be uncompressable
>> so that the attacker can not out right reject the file. It is also
>> a form of lossy text compression in the since that in some cases
>> more than 1 files compress to the same file. Your message and the
>> same message with the spurious character that sometimes appears
>> on decompression. It is also very easy to code. The only draw backs
>> that I can think of is that you aren't saving space even though it seems
>> to use about the same space as mine. However I do like the idea of loss text
>> compression but I like it to occur more as a "all or nothing" in other
>> words it is lossy but on decompression you either have the whole
>> file or garbage to pick from. Instead of the guessing if last character
>> is correct.
>
>The purpose of your one to one property needs be ensured only for
>the cycle decompression-compression-decompression (one begins
>with decompression, not compression), since the analyst, after
>trying a key, gets the compressed file, not the uncompressed
>original file. In this case it is evident that the one to one
>property holds. The other cycle compression-decompression-
>compression is what the legitimate communication partners do. There,
>as I mentioned, is the unfortunate defect of sometimes obtaining
>spurious symbols (only the first time when decompressing back, the
>file with the spurious symbols is then one to one), but the analyst,
>operating on the other cycle, never gets to see this. There is,
>however, in my view a positive tradeoff of the defect: My scheme is
>simpler in logic and hence easier to be verified to be correct.
>
>I don't yet catch your space saving argument. Space saving is the
>goal of compression, but this is done by the Huffman algorithm proper,
>isn't it? I do delete some bits under certain circumstances, but that
>saving (in percentage) is so small that it doesn't worth mentioning
>in my humble view. As far as I can understand, your scheme can't
>save more for any practical file (i.e. excepting possibly toy
>examples), since the main work is done in both cases in exactly the
>same way by the original Huffman algorithm, only the end processing
>is different.
I agree that your method is logical "simpler" but I think that since
my method makes the file esentailly the same size and no Spurious
character. It is the better method. The only rason that it might not be
is if the logic is flawed. If is is flawed find and example. There where
not many rules. Surely you can exaimine them.
Again yes the only real difference is in the "ending logic" yours is
much simpler. But why live with errors "spurious characters" when
one does not have to. Once you figure out the logic. The machine
does the work not you. So it makes little difference to the computer
which is easier. Again I say if you see a flaw in those rules. Show
me. IF you can find an exception show me.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: WT Shaw temporarily sidelined
Date: Mon, 30 Aug 1999 14:45:03 GMT
In article <[EMAIL PROTECTED]>, Eric
Lee Green <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> In article <[EMAIL PROTECTED]>, Jim Dunnett wrote:
>> >On Sat, 28 Aug 1999 19:57:15 GMT, [EMAIL PROTECTED] (don garrisan) wrote:
>> >>Bill has asked me to let you guys know that he will be off line for a
>> >>short while. Currently in the hospital, he will be back in touch with
>> >>the group as physical progress, time and laptop make it possible.
>> >
>> >Please convey my best wishes for a speedy recovery to him.
>> >
>> Which hospital is he in. maybe I can drop by and cheer him up.
>
>C'mon now, Scott, you don't want him to die from busting all his
>stitches laughing, do you? (grin).
>
Why not. IF his going to die maybe he would prefer to die laughing
than just to slow pass away in pain and agony. I think he is in Texas
is he not. Any way be kind enough to pass my offer to him. Unless
your one of those control freaks who like to take it upon himself to
decide what is best for ones friends since you know better than they
do what they want.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Louis Granboulan <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.security,comp.graphics.misc,rec.arts.movies.tech
Subject: Workshop in Paris on Watermarking and Copyright enforcement
Date: Mon, 30 Aug 1999 15:23:50 +0200
Workshop on Watermarking and Copyright enforcement
October 22 and 23, 1999
Paris, France
The goal of this workshop, as part of the APIM program (Analysis and
Protection of Multimedia Information), is to discuss the
state-of-the-art in document marking. We will focus on the following
issues:
* Insertion of a watermark in a document (image, music, java bytecode,
etc.). Ideally, this mark should be invisible and impossible to erase.
Only autorised people should be able to insert a mark and to detect the
presence of the watermark in the document.
* Marking the document with a different mark every time it is
distributed. The collusion of several different marks should not allow
to erase the mark. At least one of the original marks should be
detectable.
Invited speakers are
Joe KILLIAN, Ingemar COX, Matt MILLER from NEC Research Institute
Beno�t MACQ, Jean-Jacques QUISQUATER from Universit� catholique de
Louvain
Birgit PFITZMAN from Universit�t des Saarlandes
You can send propositions of short communications until September 18.
The talks will be in english.
Participation is free but registration before October 1st is necessary.
The meeting will take place in the main room of Jourdan's site the Ecole
Normale Superieure.
The URL with more details is : <A
HREF="http://www.apim.ens.fr/watermark.html">http://www.apim.ens.fr/watermark.html</A>.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Key Establishment Protocols - free chapter from Handbook of Applied
Date: Mon, 30 Aug 1999 10:51:54 -0400
It's a great idea. The book is a great reference, I use it alot.
People who would buy it, will buy it even if a copy exists
on the web. It's a big, heavy book, and what I beleive to be
_the_ reference book in cryptography today. A serious
cryptologue would want to have the hardcover version of
it.
Menezes, Oorschot and Vanstone did a great job, congrats!
Anton
------------------------------
** 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
******************************
