Cryptography-Digest Digest #701, Volume #12 Sun, 17 Sep 00 15:13:00 EDT
Contents:
Re: On secret Huffman compression (SCOTT19U.ZIP_GUY)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
winace encryption algorithm (No User)
Re: Serpent S-boxes (again) (Terry Ritter)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: winace encryption algorithm (Mok-Kong Shen)
Re: On secret Huffman compression (Mok-Kong Shen)
Re: Lossless compression defeats watermarks (Matthew Skala)
One-way encryption ("Thanh Diep")
Re: Killer aircraft to fly again? ([EMAIL PROTECTED])
Re: On secret Huffman compression (Benjamin Goldberg)
Re: "Warn when encrypting to keys with an ADK" (Howard (using fs))
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: On secret Huffman compression
Date: 17 Sep 2000 17:36:05 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <39C4C26B.F3DA7589@t-
online.de>:
>
>A Huffman tree for compression is built according to the
>frequncy distribution in the manner that is well-known.
>We assume that the opponent can build the same tree.
>Now we do modifications to the coding as follows such
>that the opponent cannot decompress to obtain the
>original message:
>
>Use a secret key as seed of a PRNG. At each non-terminal
>node of the given Huffman tree, use a psudo-random number
>to determine whether the two branches are to be flipped,
>i.e. whether their markings of 0/1 are to be exchanged.
>Use the modified tree to do compression.
>
>We note that in order to cater for the byte/word boundary
>issue of the output file, one can include an end-of-file
>symbol (with the least frequency) in the Huffman tree
>and after output of that symbol use random bits to fill
>to the desired byte/word boundary.
>
>M. K. Shen
>--------------------------------
>http://home.t-online.de/home/mok-kong.shen
>
Yes do that if it makes you happy.
but why not use my focused huffman its does the same thing
if you look at the code. You can supply the 0/1 switching and
padding as a function or you can modify it was random stuff.
But you already know that. However again I must point out with
mine you don't need to waste space with a useless EOF symbol
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tying Up Loose Ends - Correction
Date: 17 Sep 2000 17:41:03 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <39C5008E.CDE93C01@t-
online.de>:
>
>
>John Savard wrote:
>>
>> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>>
>> >It would be infinitely more useful to simply tell us how.
>>
>> Well, we do know that using an end-of-file code _slightly_ reduces the
>> security of encryption, at least if a simple, classical method is used
>> that doesn't have much resistance to a known plaintext attack.
>>
>> The redundancy of the whole message is increased, because space has to
>> be reserved in the table for the end-of-file code, which is only used
>> once.
>>
>> The end-of-file code constitutes known plaintext - it can have only
>> eight possible positions, with 0 to 7 irrelevant bits following it.
>>
>> This is the "how". In previous postings, Mr. Scott has indicated that
>> he believes the NSA either _can_ perform brute-force searches on
>> ciphers with 128-bit keys, or they have enough cracks on the major
>> ciphers with such keys, such as IDEA and the AES candidates, that
>> cryptanalyzing them is within the realm of possibility.
>>
>> Hence, he is advocating the most meticulous attention to compression,
>> so that after a candidate key is tried, the resulting candidate
>> plaintext generated from an incorrect key cannot be distinguished from
>> real plaintext by any simple automated test.
>>
>> Thus, while compressing better is, on general principles, a good idea,
>> he rejects the conventional wisdom, which tells us: it is very hard to
>> make compression _that_ good, and it is very easy to switch to 256-bit
>> keys.
>
>I don't think that it is worthwhile to worry about the
>slight 'increase in redundancy'. Normally, the frequency
>distribution on which the Huffman tree is based is
>only approximately true of that of the actual message
>(unless one does two passes and transmit the frequency
>distribution or its equivalent) so that arguing about
>tiny stuffs is not justified. Further, as I said in
>my follow-up, one can do a secret Huffman compression
>so that the main reason of having Scott's 1-1 no longer
>holds.
>
>M. K. Shen
>
I guess you just don't seem have the ability to understand
your method sucks. Having a EOF is just plain waste. It is added
info that is not needed. Switch the 1/0 is old hat and I have
discussed it before with you, That is not a bad idea and I
broght it up before. Think of something new for once.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Date: Sun, 17 Sep 2000 11:56:51 -0500
From: No User <[EMAIL PROTECTED]>
Subject: winace encryption algorithm
This is the secret Ace (and WinAce) encryption algorithm. It is a
combination of a Blowfish derivation and a SHA-1 derivation and it
uses Cipher Block Chaining. I called it AceFish therefore...
This code will only work on machines with Intel byte order! It
shouldn't be too difficult to adapt it for Motorola byte order,
anyway.
==== begin AceFish.h ================================================
#ifndef __ACEFISH_H__
#define __ACEFISH_H__
typedef unsigned long u32;
class AceFish {
u32 _p[18];
u32 _s[4][256];
u32 _cbc0, _cbc1; // for cipher block chaining
static void hash(const char* str, u32 hash[5]);
void encrypt(u32& res_l, u32& res_r, u32 in_l, u32 in_r);
void decrypt(u32& res_l, u32& res_r, u32 in_l, u32 in_r);
public:
AceFish(const char* password);
void encrypt(void* buffer, size_t bytes); // (bytes % 8) == 0!!
void decrypt(void* buffer, size_t bytes); // (bytes % 8) == 0!!
void resetCBC() {
_cbc0 = _cbc1 = 0;
}
};
#endif
==== end AceFish.h ==================================================
==== begin AceFish.cpp ==============================================
#include <string.h>
#include
---
This message did not originate from the Sender address above.
It was posted with the use of anonymizing software at
http://anon.xg.nu
---
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Serpent S-boxes (again)
Date: Sun, 17 Sep 2000 18:07:58 GMT
On 17 Sep 2000 16:21:43 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Mack) wrote:
>>[EMAIL PROTECTED] wrote:
>>: [EMAIL PROTECTED] (Gregory G Rose) wrote:
>>
>>:> I guess this could be considered an example of "proof by assertion",
>>:> but, has anyone actually checked the stated algorithm to see if it
>>:> does produce the chosen s-boxes?
>>
>>: The algorithm presented in the serpent paper is not complete they have
>>: a step labeled "test for given criteria" which doesn't say "how" the
>>: tests are done.
>>
>>*If* the criteria are well defined, it shouldn't matter how the tests are
>>done. For example, "non-linearity of 4" should be unambiguous, no matter
>>how you do your tests.
>
>In that specific case there are a number of measures of non-linearity.
>So it isn't really a well defined criteria.
I basically dispute this. Yes, it is true that Boolean function
nonlinearity is applied to "bit-columns" in substitutions. This gives
a nonlinearity result for each column, which are then often combined
in some way. Typically we use either the minimum or the mean, and I
have used both.
Developing two related results from exactly the same set of Boolean
function nonlinearity data hardly constitutes "a number of measures."
It is also true that "nonlinearity" originally implied a Fourier
transform of data. I speculate that this form in fact may be more
useful in the context of RNG's and stream ciphers.
But for the past decade, s-box analysis has almost exclusively used
the Walsh-Hadamard transform (and correlation to the related "affine
Boolean functions" as opposed to sine waves of different frequency)
for Boolean function analysis.
I would be most glad to receive any citations or evidence to the
contrary.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Sun, 17 Sep 2000 20:23:15 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote in
> >John Savard wrote:
> >>
> >> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
> >>
> >> >It would be infinitely more useful to simply tell us how.
> >>
> >> Well, we do know that using an end-of-file code _slightly_ reduces the
> >> security of encryption, at least if a simple, classical method is used
> >> that doesn't have much resistance to a known plaintext attack.
> >>
> >> The redundancy of the whole message is increased, because space has to
> >> be reserved in the table for the end-of-file code, which is only used
> >> once.
> >>
> >> The end-of-file code constitutes known plaintext - it can have only
> >> eight possible positions, with 0 to 7 irrelevant bits following it.
> >>
> >> This is the "how". In previous postings, Mr. Scott has indicated that
> >> he believes the NSA either _can_ perform brute-force searches on
> >> ciphers with 128-bit keys, or they have enough cracks on the major
> >> ciphers with such keys, such as IDEA and the AES candidates, that
> >> cryptanalyzing them is within the realm of possibility.
> >>
> >> Hence, he is advocating the most meticulous attention to compression,
> >> so that after a candidate key is tried, the resulting candidate
> >> plaintext generated from an incorrect key cannot be distinguished from
> >> real plaintext by any simple automated test.
> >>
> >> Thus, while compressing better is, on general principles, a good idea,
> >> he rejects the conventional wisdom, which tells us: it is very hard to
> >> make compression _that_ good, and it is very easy to switch to 256-bit
> >> keys.
> >
> >I don't think that it is worthwhile to worry about the
> >slight 'increase in redundancy'. Normally, the frequency
> >distribution on which the Huffman tree is based is
> >only approximately true of that of the actual message
> >(unless one does two passes and transmit the frequency
> >distribution or its equivalent) so that arguing about
> >tiny stuffs is not justified. Further, as I said in
> >my follow-up, one can do a secret Huffman compression
> >so that the main reason of having Scott's 1-1 no longer
> >holds.
>
> I guess you just don't seem have the ability to understand
> your method sucks. Having a EOF is just plain waste. It is added
> info that is not needed. Switch the 1/0 is old hat and I have
> discussed it before with you, That is not a bad idea and I
> broght it up before. Think of something new for once.
If my message is over one hundred bytes, do you think
that I need to care about wasting 5 bits?? The frequency
distribution is normally not corresponding to the
actual message (unless one does two passes). So what
is the point of arguing about waste?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: winace encryption algorithm
Date: Sun, 17 Sep 2000 20:25:34 +0200
No User wrote:
[snip]
You posted doubled. I have sent follow-up to the original
thread.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On secret Huffman compression
Date: Sun, 17 Sep 2000 20:39:45 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> Yes do that if it makes you happy.
>
> but why not use my focused huffman its does the same thing
> if you look at the code. You can supply the 0/1 switching and
> padding as a function or you can modify it was random stuff.
> But you already know that. However again I must point out with
> mine you don't need to waste space with a useless EOF symbol
As explained in another thread, the waste is so small
that it is not worth the effort to consider it (do you
do real-valued computations to 30 decimals?) and it is
even not justified to do so if the frequency distribution
used is only an approximate one.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Lossless compression defeats watermarks
Date: 17 Sep 2000 11:28:36 -0700
In article <[EMAIL PROTECTED]>,
Niklas Frykholm <[EMAIL PROTECTED]> wrote:
>Google --- pages 6--7, which mentions just this problem. A watermark has
>to change the perceived content. Hopefully the change is so small that it
>will not be noticed.
It's worse than that, because if the change is small enough not to be
noticed, then you might as well turn up the lossy compression a little
further. Really, watermarks must change the perceived content in a way
that the user *isn't* willing to tolerate!
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: "Thanh Diep" <[EMAIL PROTECTED]>
Subject: One-way encryption
Date: Sun, 17 Sep 2000 14:46:59 -0400
Hi,
I am looking for an one-way encryption algorithm to encrypt passwords of
about
20-character in length.
I have been scanning various news group without much success. A few
algorithms
mentioned were: 3DES, MD5, SHA-1 and RIPE MD160, but I have no ideas where
to
get them or how to implement.
Ideally, I would like to have an algorithm to incorporate in my system but
will
settle for a dll. My development platform is J++ on NT 4.0 and the
application
is running on the server side only. Please bear in mind that this is a
commercial application.
Thank you in advance for your help.
Regards,
Thanh Diep
(Please send a copy of your suggestion/solutions to [EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.military.naval,alt.conspiracy,sci.geo.earthquakes
Subject: Re: Killer aircraft to fly again?
Date: Sun, 17 Sep 2000 18:48:29 GMT
17 September 2000 – 19 September 2000
Sept. 18, 2000
http://www.geocities.com/antarii_rescue/TOMBShistory.html
http://www.geocities.com/antarii_rescue/index2.html
http://www.geocities.com/chemosh_of_ammon/NGC1987A.html
http://boudiccaarran.tripod.com/index.html
Active Warnings:
********** VERY LIKELY SHORT WAVE FADEOUT *************
MAGNETIC SHEARING
GEOSYNCHRONOUS MAGNETOPAUSE CROSSINGS
[sometime during the UTC day of 19 September]
** Major Solar Flare Associated CME is directed Earthward **
****Auroral Activity Warning Issued for 19 Sept 2000 ****
This warning will remain in effect until further notice.
A major solar flare (x-ray class M5.9, optical size 2B [Brilliant
in hydrogen-alpha]) erupted from a rapidly developing sunspot region at
04:26 UTC on 16 September. This major flare was associated with a full
halo coronal mass ejection that is directed Earthward.
The Earth's magnetosphere is expected to observe a nearly head-on
collisional impact by this solar disturbance sometime during the UTC
day of 19 September.
The active sunspot region may still be capable of producing
an additional major proton flare over the next several days.
********** VERY LIKELY SHORT WAVE FADEOUT *************
MAGNETIC SHEARING
GEOSYNCHRONOUS MAGNETOPAUSE CROSSINGS
[sometime during the UTC day of 19 September]
http://www.geocities.com/antarii_rescue/TOMBShistory.html
http://www.geocities.com/antarii_rescue/index2.html
http://www.geocities.com/chemosh_of_ammon/NGC1987A.html
http://boudiccaarran.tripod.com/index.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: On secret Huffman compression
Date: Sun, 17 Sep 2000 19:02:44 GMT
SCOTT19U.ZIP_GUY wrote:
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote in
> <[EMAIL PROTECTED]>:
>
> >A Huffman tree for compression is built according to the
> >frequncy distribution in the manner that is well-known.
> >We assume that the opponent can build the same tree.
> >Now we do modifications to the coding as follows such
> >that the opponent cannot decompress to obtain the
> >original message:
> >
> >Use a secret key as seed of a PRNG. At each non-terminal
> >node of the given Huffman tree, use a psudo-random number
> >to determine whether the two branches are to be flipped,
> >i.e. whether their markings of 0/1 are to be exchanged.
> >Use the modified tree to do compression.
> >
> >We note that in order to cater for the byte/word boundary
> >issue of the output file, one can include an end-of-file
> >symbol (with the least frequency) in the Huffman tree
> >and after output of that symbol use random bits to fill
> >to the desired byte/word boundary.
>
> Yes do that if it makes you happy.
>
> but why not use my focused huffman its does the same thing
> if you look at the code. You can supply the 0/1 switching and
> padding as a function or you can modify it was random stuff.
> But you already know that. However again I must point out with
> mine you don't need to waste space with a useless EOF symbol
Unless I'm mistaken, Mok-Kong Shen's code does not do the same thing as
your huffman code; Your code is an adaptive huffman code, his is a
static code. Also, with his code, you don't need an EOF either, in most
cases... if the tree was based on 8-bit symbols, and we need 1..7 bits
to fill out the last 8-bit byte, we can simply choose some symbol whose
huffman code is longer than 8 bits, and write out part of it. Also, the
huffman tree is probably small enough that, for PK encryption, we can
encrypt it along with a symmetric key inside the PK block.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (Howard (using fs))
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Sun, 17 Sep 2000 19:08:14 GMT
On Tue, 05 Sep 2000 18:49:39 GMT, "Nathan Williams"
<[EMAIL PROTECTED]> wrote:
>
> <snipped, and re-ordered>
>
>Maybe <....> I can usually reconnize bullshit when I see it. I
>think you are full of it.
>
Hey! Have they switched Selective Availability back on?
>
>Maybe it is your idea of a silly joke but I think your just a troll.
>
[Apologies to the group if it's bad form to respond to this chiding.]
Neither. I posted in good faith, about my surprise at finding an
ADK'd key on my keyring when most posters were saying they hadn't seen
one, and noting that without a copy of the ADK itself on my keyring,
the so-called 'ADK bug' could not have any effect.
I posted from Europe too, and the names you mention are not familiar
to me, but the organisations are. They are, though, only US
organisations, each country has similar organisations. The 'silly
joke' is a very US-oriented joke - I think I stumbled onto a US
battleground between pro and anti ADK camps. My reading of another
poster responding to you seems to suggest that. I'm not an
experienced or confident user of PGP, and would be the first to admit
that I do not understand enough of keys, signatures, trust, and ADKs
etc. My nervous surprise at finding an (apparently rare) ADK'd key on
my machine, paled into insignificance when I read your post! I can't
see whose the signatures are or whose the 'ADK' is, only the signature
hex ids and ADK hex ids are shown on 553ckt, which I have tried to
use. I'm inclined to agree with you that the key is bogus, in the
light of the user ids you posted and noting your point that no
corroborative signatures were attached. Your post itself has taught
me a lot although I think I've learned it the hard way! I think I've
been had!
My key ring is full of keys with 'unknown signers', and I've no idea
who the 'unknown signers' are. So whenever I've visited a website
dealing with crypto etc, and someone offers a key, I've downloaded it
and added it to the key ring, hoping that it might plug some of the
gaps in the 'unkown signers'. It doesn't seem to have done, though.
And I think that indiscriminate 'harvesting' of keys is probably
pointless. More seriously, I think now that it can be positively
stupid if it leads to potentially using or depending on keys which
really could be anything. Perhaps I should start again with a blank
ring.
I'm going to summarise here what this episode has taught me, it might
help somebody - I sense I'm not going to be the last to trip this way.
1 I've learned that it's not a good idea to just acquire keys from
anywhere.
2 I've learned that a key might not be what it seems to be.
3 I've learned that you have to validate the key by checking the
signatures, it is not enough simply that the key is signed.
4 And as a consequence, you should never, ever, use a key that you
don't absolutely trust and know where it came from.
>
>That NAI key is bogus. All NAI keys are countersigned by other NAI
>keys and usually Phill Z and Will Price.
>
I didn't know that. It's interesting that some other recent posts in
alt.security.pgp are raising the same issues about verification of the
NAI keys, necessitating the same response as you made about how the
real NAI keys are signed by PZ and WP. I'm not the only person, I
think, who does not understand properly how to validate an NAI key.
>
>my
>email to you splashed.
><.....>
> Email : [remove the obvious]hcsc[at]tesco[dot]net
>
The header on the posting is a spamtrap, but the email address in the
body is good. It's an address used by all our family, by the way.
There was, and is, no act or intention to deceive or disguise. I will
continue to post, in good faith, and will continue to include a good
email address.
Sorry about the long post. It's been my first flame, and I was a bit
taken aback. Still, now I feel an accredited member of usenet!
--
Howard
Email : [remove the obvious]hcsc[at]tesco[dot]net
------------------------------
** 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
******************************
