Cryptography-Digest Digest #213, Volume #10 Thu, 9 Sep 99 22:13:02 EDT
Contents:
Re: Source code ("Daniel Roethlisberger")
[q] gnupg strength ([EMAIL PROTECTED])
Re: unix clippers that implement strong crypto. (Paul Rubin)
Re: compression and encryption (Anton Stiglic)
Re: NSAKEY as an upgrade key (Was: NSA and MS windows) ("Trevor Jackson, III")
Re: NSAKEY as an upgrade key (Was: NSA and MS windows) ("Trevor Jackson, III")
Re: some information theory (John Savard)
Re: some information theory (John Savard)
Re: some coder/hacker help please? ("John E. Kuslich")
Re: some information theory (SCOTT19U.ZIP_GUY)
Re: some information theory (SCOTT19U.ZIP_GUY)
Re: GnuPG 1.0 released (Walter Hofmann)
H.235 Keys from Passwords algorithm ("Douglas Clowes")
Re: NSAKEY as an upgrade key (Was: NSA and MS windows) (Bill Unruh)
Re: some coder/hacker help please? (John Bailey)
Re: some information theory ("rosi")
Re: some information theory ("karl malbrain")
Re: some information theory ("karl malbrain")
Re: GnuPG 1.0 released (Vernon Schryver)
Looking for Completely-Free Strong Algorithms ("Joseph Ashwood")
Re: some information theory ("rosi")
----------------------------------------------------------------------------
Reply-To: "Daniel Roethlisberger" <[EMAIL PROTECTED]>
From: "Daniel Roethlisberger" <[EMAIL PROTECTED]>
Subject: Re: Source code
Date: Fri, 10 Sep 1999 00:05:19 +0200
> Actually if an American copies that code though British and places it
> in a working program. That individual still can not export it with out
> approval. It makes no difference where the crypto came from. The point
(...)
Well, I have understood his question differently. I thought he was a non-US
guy interested in getting strong crypto. If he's a US guy, he should give up
doing it legally exportable. 'Cos 40 bits are weak - too weak for any
secret.
/Dan
--
[EMAIL PROTECTED]
PGP Key ID 0x326DA8BA
virus scanners, eat eicar.com:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
------------------------------
From: [EMAIL PROTECTED]
Subject: [q] gnupg strength
Date: Thu, 09 Sep 1999 22:13:12 GMT
could anybody versed or familiar with the algorithms of pgp and gnupg
explain the relative strength of the gnupg system as compared to pgp2?
is gnupg going to be worth the time of setting up and building new
public keys and distributing them to all my friends?
jhs
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: comp.security.unix
Subject: Re: unix clippers that implement strong crypto.
Date: 9 Sep 1999 20:58:11 GMT
In article <[EMAIL PROTECTED]>,
Armin Ollig <[EMAIL PROTECTED]> wrote:
>iam working on a solution for encrypting backups to a mag-tape.
>The application i need would be a symetrical clipper that reads
>the unencrypted stream from standard in and writes the encrypted
>stream to standard out.
I think by "clipper" you mean to say "filter".
>Wherer can i find an implementation of IDEA or Blowfish that comes with
>the source code ?
Blowfish source can be found on Peter Gutmann's web page or various
other places. If you are running Linux, I have a version of GNU tar
that has a Blowfish encryption option added. Unfortunately due to
US government idiocy I can't send it outside the US in electronic
form, but I guess I could (ugh!) print out the code and send it to
you on paper.
>Or do i really need to mess around with pgps source in order to stop
>this temp file nonsense .....
No it's not worth messing with pgp. You don't want anything like
pgp's features.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: compression and encryption
Date: Thu, 09 Sep 1999 17:36:38 -0400
I saw the begining of your web page on compression. I
think you got the definition of entropy wrong, or are using
it incorectly. One way to define the entropy of a source is the
average lenght needed to encode the output of that source, by
definition this will be the lenght of the output after it has been
compressed by a perfect compression scheme. So there is no
difference between the entropy of a source of english messages
and a corresponding source of compressed english messages.
Anton
------------------------------
Date: Thu, 09 Sep 1999 18:23:50 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NSAKEY as an upgrade key (Was: NSA and MS windows)
Larry Lee wrote:
> With all the excitement over the NSAKEY and breaking the 512 bit key,
> I figured I lurk here awhile and see what the big boys thought. Ha!
>
> With respect to the NSAKEY, there seem to be two plausible explanations
> 1) Never attribute to malice what can be explained by stupidity.
> Microsoft put it in for testing or some unimplemented and long forgotten
> project and left it in because no one is sure why its there and is afraid
> they'll break something if they take it out.
>
> OR
> 2) Andrew Fernandes has correctly identified its real use, it is a second
> key which is intended to be overwritten by the end user before it is
> used by private applications.
>
> With respect to the 512 bit key
> Researchers have broken the 512 bit key with 7 months of non-dedicated
> computer time and a final burst of effort on a big matrix machine.
> I don't understand the process and don't really care.
>
> What is of interest though, is that if a 512 bit composite number
> can be factored, then factoring Microsoft's 128 bit composite number
> ought to be much simplier perhaps on the order of days or weeks.
> Microsoft's release cycle is several years long, so the useful life
> of the 128 bit key that's burned onto the CDROM must be many years.
>
> Why would anyone believe that the NSA, Hackers'R'US, or the Chinese
> government haven't factored the number and aren't issuing their own
> certificates. The benefits resulting from the effort would last for
> years.
>
> Comments?
"Cracking" the Microsoft(tm) key is probably not the cheapest method for
compromising the system. Microsoft(tm) is vulerable to government decision, so
might be "persuaded" by a combination of threats and inducements to surrender
the key.
Non-US-government actions might by aimed at cracking the security surrounding
the storage of the key. I doubt Microsoft(tm) has a counter-intelligence
department on the scale of even a minor country.
------------------------------
Date: Thu, 09 Sep 1999 18:19:15 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NSAKEY as an upgrade key (Was: NSA and MS windows)
Thomas J. Boschloo wrote:
> "Trevor Jackson, III" wrote:
> >
> > Thomas J. Boschloo wrote:
> >
> > > "Trevor Jackson, III" wrote:
> > > >
> > > > [EMAIL PROTECTED] wrote:
> > > >
> > > > > Thomas J. Boschloo ([EMAIL PROTECTED]) wrote:
> > > > > : Microsoft's explanation "Why is a backup key needed?" is bogus (they
> > > > > : claim it would be needed for when the building in which it is kept is
> > > > > : destroyed by a natural disaster, LOL).
> > > > >
> > > > > Well, while keeping two copies of the key would solve that, two copies of
> > > > > the same secret key won't help if one key is _compromised_. For that, a
> > > > > second key, to which the corresponding secret key is stored _elsewhere_,
> > > > > would serve a useful backup function.
> > > >
> > > > This only makes sense if there is a revocation mechanism for the primary
> > > > key. Do you see such a mechanism?
> > >
> > > MS could issue a patch when the first key was compromised.. They do that
> > > all the time ;-)
> >
> > OIC. They could issue a patch. But if the backup key were not available they
> > could _not_issue a patch? Are you serious?
>
> MS could issue a patch that disabled the first key in Windows. They can
> do anything. Allowing controls signed with the first key would not be an
> option, since the key was compromised.
Right. By this line of logic there is no need for a "backup" key. Thus the "bakup
key" most have some purpose other than backing up the functionality of the primary
key.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: some information theory
Date: Thu, 09 Sep 1999 22:04:21 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>In article <[EMAIL PROTECTED]>,
> "Sam Simpson" <[EMAIL PROTECTED]> wrote:
>> I suggest you take a look at: D.Wagner, S.Bellovin, "A Programmable
>> Plaintext Recognizer", 1994 - it shows that compression IS useful
>> against some attacks.
>I will just wait till there is a 'programmable compressed text
>recognizer". My point is that the amount of information has not changed
>thus the message is no more random.
The length of the message has changed.
If the message shrinks to fit the amount of information it contains
exactly, it would be random - in appearance.
Essentially, there are N valid 1024-byte uncompressed text messages.
Supposing your compression method compresses a 1024-byte message to
512 bytes.
Not all the messages will compress to the same length, but if that
compression performance was "average" for your compression method, the
number of valid 512-byte _compressed_ messages will be approximately N
as well.
Not sqrt(N).
Message entropy hasn't changed. Entropy _per byte_ has increased.
That's your fallacy in the information theory area.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: some information theory
Date: Thu, 09 Sep 1999 22:05:39 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>Entropy is a measure of content, it can apply to a source or two a message.
>For example a switch 'male'/'female' while requiring 7 bytes of ram, has only
>1 bit of informatiuon. If your measage is english, chances are there are
>about 1.3 bits of information per character (or byte). And no matter what
>you do to the message, unless you add or remove content the entropy of the
>message (in whatever form) remains the same.
Right. And if that's my message, compressing it to 1 bit *does* make
it random: entropy=message size.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: some coder/hacker help please?
Date: Thu, 09 Sep 1999 16:19:48 -0700
The source code file appears to be corrupted. I tried downloading it twice and
each time winzip barfed...complaining that the file was bogus.
JK http://www.crak.com Password Recovery Software
Tom St Denis wrote:
> I have (as everyone knows) released PeekBoo ([1]). I have just put out a
> 'v1.3' which addresses some errors (security wise) that I have found. I
> would like however others to attack it as well. The program unfortuneatly is
> limited to symmetrical encryption but it serves it's purpose well. Basically
> I want to try and find any memory 'leaks' where key bits or password bits are
> left in memory and the like.
>
> [1] The program and source code can be found at
> http://people.goplay.com/tomstdenis/pb.html
>
> I know there are good crypto/coder/hacker people out there, and I would
> appreciate any feedback. Also are there any good compact number libraries (I
> can only find LIP which compiles...) I need one in normal C. LIP doesn't
> compile with LCC-WIN32 though (only gcc 2.8.1) ... any pointers?
>
> Tom
> --
> damn windows... new PGP key!!!
> http://people.goplay.com/tomstdenis/key.pgp
> (this time I have a backup of the secret key)
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: some information theory
Date: Fri, 10 Sep 1999 00:45:20 GMT
In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
>>
>
>If your compression function is known, then you have no advantage in
>compressing for what concerns entropy, the entropy will be the same.
>You can convince yourself of this easily, entropy is a mesure of certainty
>of the output of a source, just compress that output and you get a source
>that outputs compressed data, beeing able to predict one implies you can
>predict the other.
>
Since you are going to talk entropy. In a one to one compression scheme
entropy will be the same before compression and after compression. But
the entropy density ( entropy per bit ) will increase if the file gets
smaller. However if the compression method sucks you may be helping
the enemy break your code.
However that being said if you use a dumb compressorer it can decrease
the overall entropy of the total system. Here is why. Suppose there was
only 2^64 messages that you might send and your using a TOMMY boy
encryption methed that has a 56 bit key. You try and guess which key was
used. You may try all the combinations. And find that 8 of the messages
are equallt likely. Well at least you reduce the cases down.
However Now lets suppose Tommy is useing an inferior compresstion
method. Maybe it has a BTW transform and what ever with a MTF and REL
whateever. But know when you test all 2^56 keys with the message and do
the uncompress maybe only 2^48 actaully are valid compressed files by the
method choosen. And it may be likely that only one of them is in the original
set of 2^64 message. Thank god tommy choose to use a compression method
that was not one to one.
>In most crypto algorithms that use a compression function, the function
>is known, or easily deduced (if it is an existing one, it can be found). If
> the
>
>compression function is unknown it's most likely that it has been kept secret
>(but if you can exchange a compression function in secret, why not exchange
>the secret itself or a one time pad).
>
>That's the bottom line.
No its not the bottom line. It makes a big differnce which compression
method you use thats the bottom line.
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: some information theory
Date: Fri, 10 Sep 1999 00:28:06 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>Anti-Spam wrote:
>>
>
>> For example, let's say this is the message in SYMBOLS:
>>
>> T H E M E S S.......
>>
>> when encoded before compression, in binary,
>>
>> 001001 101011 001001 110111 001001 101010 101010
>>
>> But, when compressed, T now is encoded as 0111, H as 0011, E as 01, S as
>> 10101, M as 1001...
>> (just examples, didn't do the math for the encoding.....)
>>
>> 0111 0011 01 1001 01 10101 10101
Don't forget since this discussion was about adaptive huffman
coding so that by the time the second "E" or second "S" is used
they may not be the same as when first encoded. It is a dynamically
changing table.
>>
>> We see the bit length of the message is shrinking with the new encoding,
>> but note the occurances of the new codes follows the relative ordering
>> of the occurances of the uncompressed code. An e no matter how encoded
>> still follows the H no matter how encoded. A T starts the message, no
>> matter how encoded. We can define a point-set topology on the SYMBOLS
>> as they occur in the original message, and we can show that this
>> point-set topology is preserved by the compression.
>
>Yes, the same sequence of symbols is there and, of course, the
>symbols have the same frequencies as in the original file. But the
>analyst looking at the binary string of the compressed file has first
>to find out the boundaries between the symbols in the compressed file
>(the size of the symbols being non-constant) before he can do any
>frequency count. So it could be argued that compression does render
>his job more difficult, unless he can somehow obtain knowledge of
>the Huffman tree (e.g. in case the table is attached to the data file).
>I am interested to know what counter-arguments could be given
>against this.
>
>M. K. Shen
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: Walter Hofmann <[EMAIL PROTECTED]>
Subject: Re: GnuPG 1.0 released
Date: Fri, 10 Sep 1999 00:43:34 +0200
Charles Blair <[EMAIL PROTECTED]> wrote:
> GnuPG says they don't have any patent problems. Did they get
> permissions from McAfee, RSA, PGP partners, etc, or have the patents
> in question expired?
GnuPG doesn't implement RSA or IDEA. So you won't have much fun
communicating with people who use PGP 2.x. You can, however, get the
rsa.c, rsaref.c and idea.c modules from the "contrib" directory on their
website and easily add support for IDEA and RSA yourself.
Walter
------------------------------
From: "Douglas Clowes" <[EMAIL PROTECTED]>
Subject: H.235 Keys from Passwords algorithm
Date: Fri, 10 Sep 1999 10:07:34 +1000
Section 10.3.2 of ITU-T H.235 states in part:
The encryption key is length N octets (as indicated by the AlgorithmID), and
is formed as follows:
� If password length = N, Key = password;
� if password length < N, the key is padded with zeros;
� if password length > N, the first N octets are assigned to the key,
then the N + Mth octet of the password is XOR'd to the Mmod(N)th octet (for
all octets beyond N) (i.e. all "extra" password octets are repeatedly folded
back on the key by XORing).
is it just me, or is this less than secure for generating keys to be used in
algorithms like RC2, DES, 3DES, MD5, SHA1?
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: NSAKEY as an upgrade key (Was: NSA and MS windows)
Date: 10 Sep 1999 01:07:51 GMT
In <[EMAIL PROTECTED]> "Thomas J. Boschloo" <[EMAIL PROTECTED]> writes:
>MS could issue a patch that disabled the first key in Windows. They can
>do anything. Allowing controls signed with the first key would not be an
>option, since the key was compromised.
Would be hard since all of the CryptoAPI programs are signed with it,
and if it were invalidated, nothing in the base system would load.
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: some coder/hacker help please?
Date: Fri, 10 Sep 1999 01:03:06 GMT
On Thu, 09 Sep 1999 16:19:48 -0700, "John E. Kuslich" <[EMAIL PROTECTED]>
wrote:
>The source code file appears to be corrupted. I tried downloading it twice and
>each time winzip barfed...complaining that the file was bogus.
I get the same result.
John
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Thu, 9 Sep 1999 20:53:23 -0400
Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
[snip]
>to find out the boundaries between the symbols in the compressed file
^^^^^^^^^^
Sorry Mok-Kong for the plag. Should have read yours first before shooting
mine.
--- (My Signature)
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Thu, 9 Sep 1999 17:45:56 -0700
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote in message
news:7r9gra$2jm8$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]>
wrote:
> >>
> >
> >If your compression function is known, then you have no advantage in
> >compressing for what concerns entropy is or is not zero.
>>
Since you are going to talk entropy. In a one to one compression
scheme
> entropy will be the same before compression and after compression
YOUR AN IDEALIST, sorry, Karl M
But
> the entropy density ( entropy per bit ) will increase if the file gets
> smaller. However if the compression method sucks you may be helping
> the enemy break your code.
>
> However that being said if you use a dumb compressorer it can decrease
> the overall entropy of the total system. Here is why. Suppose there was
> only 2^64 messages that you might send and your using a
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Thu, 9 Sep 1999 17:47:38 -0700
Anton Stiglic <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >
>
> If your compression function is known, then you have no advantage in
> compressing for what concerns entropy, the entropy will be the same.
> You can convince yourself of this easily, entropy is a measure of
certainty
> of the output of a source, that's SOURCE in OP AMP terminology, just
compress that output and you get a source
> that outputs compressed data THAT's a reference now.
, beeing able to predict one implies you can
> predict the other.
No, only the TOTAL is squared with reality. Karl M
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: GnuPG 1.0 released
Date: 9 Sep 1999 18:49:46 -0600
In article <7r8vj6$e3h$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
>> GnuPG says they don't have any patent problems. Did they get
>> permissions from McAfee, RSA, PGP partners, etc, or have the patents
>> in question expired?
>
>I think one of the design goals of GnuPG was to use only algorithms
>without patents, e.g. ElGamal. The PGP message formats are described
>as an RFC, so no problems there.
I have no clue about any patents relevant to GnuPG, but please note
that many things patented notions are now described in RFC's.
One of the results of the PPP CCP mess (PPP compression stalled
for 2+ years by a pair of bogus Motorola/Codex patents filed,
according to someone who worked at Codex at the time, with the
express purpose of slowing other outfits down) was that the IETF
tries to handle patents much as the IEEE does. As long as the
patent holder claims to offer "reasonable and nondiscriminatory
terms and conditions", patents are ok even in standards-track RFC's.
I've also no clue what are considered "reasonable and nondiscriminatory
terms and conditions," but I am either somewhat experienced or cynical.
What the Free Software Foundation says about patents is not legal advice
that I would bet my life savings on. For years the FSF excused the GNU
support for decompressing LZW by claiming that the LZW patent was only
about compression, and never mind that about half of the ~150 claims in
4,558,302 contain the word "decompression."
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Looking for Completely-Free Strong Algorithms
Date: Thu, 9 Sep 1999 18:19:32 -0700
I'm looking for royalty-free strong algorithms. I know that AES (when it's
decided) will meet the criteria, but I need something fairly soon, and I
need it to have free source code available also (not enough time to do it
right myself). Now before Scott plugs himself again, let me say that this
encryption will be used for bidirectional communication so treating
everything as a single block simply will not work. I thank you for putting
up with my questions (although I've only asked a couple over the years), I
really do appreciate it.
Joseph
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Thu, 9 Sep 1999 20:50:38 -0400
SCOTT19U.ZIP_GUY wrote in message <7r8c6v$38js$[EMAIL PROTECTED]>...
>In article <[EMAIL PROTECTED]>, Anti-Spam
<[EMAIL PROTECTED]> wrote:
>
[snip]
>huffman coding. One other point in useing adaptive huffman compression
^^^^^^^^
May tell some amongst other things. Don't know if 'unit' boundary is
important
as well.
--- (My Signature)
------------------------------
** 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
******************************
