Cryptography-Digest Digest #697
Cryptography-Digest Digest #697, Volume #12 Sun, 17 Sep 00 07:13:01 EDT
Contents:
Re: QUESTION ABOUT ALGORITHMS ("Paul Pires")
New and recent books from Wiley (CryptoBook)
RC4: Tradeoff key/initialization vector size? (Stephan Gehring)
Re: Double Encryption Illegal? (Paul Schlyter)
Re: Double Encryption Illegal? (Paul Schlyter)
Re: Extremely slow in DES software implementation ("Kasper Pedersen")
Re: Intel's 1.13 MHZ chip (Vernon Schryver)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: QUESTION ABOUT ALGORITHMS (Serge Paccalin)
Re: RC4: Tradeoff key/initialization vector size? (David Crick)
Re: ExCSS Source Code (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Re: Question on self-shrinking (Francois Grieu)
Re: RC4: Tradeoff key/initialization vector size? (Tom St Denis)
Re: Double Encryption Illegal? (Tom St Denis)
Re: SDMI Crypto Challenge (Tom St Denis)
Re: QUESTION ABOUT ALGORITHMS (Mok-Kong Shen)
From: "Paul Pires" [EMAIL PROTECTED]
Subject: Re: QUESTION ABOUT ALGORITHMS
Date: Sat, 16 Sep 2000 22:42:51 -0700
Big Boy Barry [EMAIL PROTECTED] wrote in message
news:t9Xw5.3209$[EMAIL PROTECTED]...
If someone publsihes an algorithm, can someone else patent it?
Nope. Well depends, as long as the inventor is the one fileing and no more than
one
year has gone by .
Except in some weird situations, the inventor is the only one who can seek
a patent for the material.
Paul
"Melinda Harris" [EMAIL PROTECTED] wrote in message
news:hBKw5.30993$[EMAIL PROTECTED]...
Ladies and Gentlemen
Can anyone tell me how to patent an algorithm. Where to go. What to sign
and
how much it costs???
Any response would be greatly appreciated
EIA
--
From: [EMAIL PROTECTED] (CryptoBook)
Subject: New and recent books from Wiley
Date: 17 Sep 2000 06:00:28 GMT
16 September 2000
Classical Crypto Books is pleased to announce the following recent update to
the CCB catalog focusing on: New and recent books from John Wiley Sons.
COMPUTER SECURITY
SECRETS AND LIES: Digital Security in a Networked World
by Bruce Schneier
When Bruce Schneier wrote Applied Cryptography, he thought cryptography was The
Answer for digital security. Now he knows how naive he was and how difficult
the problem really is. Highly accessible, thoughtful; must read for every
computer user. Published at $29.99.
HB, John Wiley Sons, 2000, 431 pp.
Nonmember $27.95, Member $24.95
BIOGRAPHIES AND MEMOIRS
ALLAN PINKERTON: The First Private Eye
by James Mackay
Pinkerton, synonymous with security/protection. His trademark, an eye,
inspired the term "private eye". As Lincoln's spymaster, he managed a network
of spies behind Confederate lines. "A man at once deeply admirable and quite
obnoxious." -- The Times. Published at $27.95.
HB, John Wiley Sons, 1997, 256 pp.
Nonmember $25.95, Member $23.95
CRYPTOLOGY
THE BIT AND THE PENDULUM: From Quantum Computing to M Theory -- The New Physics
of Information
A friendly guide to a revolution now taking place at the forefront of science.
Bits are us, and everything else too, or so it seems. A lighthearted approach
to some weighty ideas, including quantum cryptography, quantum teleportation,
and wetware. Published at $27.95.
HB, John Wiley Sons, 2000, 287 pp.
Nonmember $25.95, Member $23.95
THE TWOFISH ENCRYPTION ALGORITHM: A 128-Bit Block Cipher
by Bruce Schneier
Published at $49.99.
HB, John Wiley Sons, 1999, 202 pp.
Nonmember $46.95, Member $42.95
PROGRAMMING
CRYPTOGRAPHY FOR VISUAL BASIC: A Programmer's Guide to the Microsoft CryptoAPI
by Richard Bondi
The little-known, CryptoAPI is a large collection of strong crypto routines
that come for free with Windows. Difficult to use, until now. This book
supplies interface code and describes how to call, and use, the central crypto
routines from Visual Basic. Includes a CDROM. Published at $49.99.
SB, John Wiley Sons, 2000, 479 pp.
Nonmember $45.95, Member $41.95
APPLIED CRYPTOGRAPHY (SECOND EDITION): Protocols, Algorithms, and Source Code
in C
Published at $79.99.
HB, John Wiley Sons, 1996, 783 pp.
Nonmember $74.95, Member $69.95
APPLIED CRYPTOGRAPHY (SECOND EDITION): Protocols, Algorithms, and Source Code
in C
by Bruce Schneier
Published at $54.99.
SB, John Wiley Sons, 1996, 783 pp.
Nonmember $49.95, Member $43.95
CURRENT AFFAIRS
THE ELECTRONIC PRIVACY PAPERS: Documents on the Battle for Privacy in the Age
of Surveillance
by Bruce Schneier
Published at $59.99.
HB, John Wiley Sons, 1997, 765 pp.
Nonmember $55.95, Member $50.95
HISTORY
WAR BENEATH THE SEA: Submarine Conflict During World War II
by Peter Padfield
Published at $30.00.
HB, John Wiley Sons, 1995, 576 pp.
Nonmember $27.95, Member $25.95
INTELLIGENCE
MACARTHUR'S UNDERCOVER WAR: Spies, Saboteurs, Guerrillas, and Secret Missions
by William B. Breuer
Published at $24.95.
HB, John Wiley Sons, 1995, 271 pp.
Nonmember $22.95,
Cryptography-Digest Digest #698
Cryptography-Digest Digest #698, Volume #12 Sun, 17 Sep 00 09:13:00 EDT
Contents:
Re: RC4: Tradeoff key/initialization vector size? (Guy Macon)
Re: RC4: Tradeoff key/initialization vector size? (Paul Rubin)
Dangers of using same public key for encryption and signatures? (Paul Rubin)
Re: Lossless compression defeats watermarks (Niklas Frykholm)
Re: Capability of memorizing passwords (Chris Rutter)
Re: RC4: Tradeoff key/initialization vector size? (Guy Macon)
Re: Dangers of using same public key for encryption and signatures? ("Brian Gladman")
Re: Double Encryption Illegal? (Mok-Kong Shen)
On secret Huffman compression (Mok-Kong Shen)
Re: Double Encryption Illegal? (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: RC4: Tradeoff key/initialization vector size?
Date: 17 Sep 2000 11:35:34 GMT
Tom St Denis wrote:
David Crick [EMAIL PROTECTED] wrote:
From the CipherSaber[-1] documentation (http://ciphersaber.gurus.com)
The user key is a text string, rather than a hex value, because
humans are more likely to be able to memorize a text string with
sufficient entropy. To leave room for the initialization vector,
the length of the user key must be less than 246 bytes. To insure
adequate mixing of the initialization vector and user key, we
recommend you select a user key of 54 bytes or less.
I would strongly recommend against using ASCII text as the key for
RC4. You should really hash it first.
I believe that the implementation of RC4 described on the web
page [ http://ciphersaber.gurus.com ] is secure without any
such hashing. Ciphersaber has withstood a lot of analysis
and attacks so far.
The reason I reference Ciphersaber instead of RC4 is because
the Ciphersaber implementation of RC4 (ARCFOUR, really - none of
us has proof that what we are looking at is really RC4) is
that it has a standard set of decisions concerning such mundane
details as whether the key is ASCII, how big the initialization
vector shouild be, etc. that have withstood a lot of scrutiny.
--
From: Paul Rubin [EMAIL PROTECTED]
Subject: Re: RC4: Tradeoff key/initialization vector size?
Date: 17 Sep 2000 04:48:21 -0700
[EMAIL PROTECTED] (Guy Macon) writes:
I believe that the implementation of RC4 described on the web
page [ http://ciphersaber.gurus.com ] is secure without any
such hashing. Ciphersaber has withstood a lot of analysis
and attacks so far.
Are you kidding?
--
From: Paul Rubin [EMAIL PROTECTED]
Subject: Dangers of using same public key for encryption and signatures?
Date: 17 Sep 2000 04:56:46 -0700
Current practice seems to prefer using two separate keys, though some
systems (PGP 2.x, and effectively SSL) use the same public key for
both encryption and authentication. I have an application where space
for keys is quite scarce. I'd like to use the same key (point on
elliptic curve) for both encryption and signing (El-Gamal / ECDSA).
What kind of trouble am I asking for, aside from the "FBI attack"
(they make you turn over your decryption key so they can read
something, and that means they can also sign your name to stuff)?
Also, how long do my keys need to be to satisfy the paranoids in this
crowd? Assume I'm using some constant (shared) curve over GF(p) for
some large p. Is 140 bits enough? How about 170? Robert Harley has
been breaking ECDL over GF(2^n) for n=112 or so, IIRC. But those are
easier than GF(p) curves.
thanks
--
From: [EMAIL PROTECTED] (Niklas Frykholm)
Subject: Re: Lossless compression defeats watermarks
Date: 15 Sep 2000 07:34:39 GMT
In article 8ps1ov$rt4$[EMAIL PROTECTED], Matthew Skala wrote:
It seems to me that this should be obvious, but my impression is that most
people don't quite realize it, so I'd just like to point it out:
If a watermarking scheme works perfectly (in the sense of being
inmperceptible by humans) and a lossy compression scheme works perfectly
(in the sense of maximizing compression without harming perceptual
quality) then compressing and decompressing a signal will have the effect
of removing the watermark.
That's perfectly true, and I think it's recognized now by (some of the)
people in the watermarking business. (Anyone else getting the feeling
that the people who do watermarking are more often Image Processing than
Security experts?)
See for example "A review of watermarking principles and practices" by
Miller, Cox, Linnartz Kalker --- it's available online just search on
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.
// Niklas
--
From: Chris Rutter [EMAIL PROTECTED]
Subject: Re: Capability of memorizing passwords
Date: Sun, 17 Sep
Cryptography-Digest Digest #699
Cryptography-Digest Digest #699, Volume #12 Sun, 17 Sep 00 09:13:00 EDT Contents: wince encryption algorithm (An Metet) From: An Metet [EMAIL PROTECTED] Subject: wince encryption algorithm Date: Sun, 17 Sep 2000 09:12:15 -0400 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 shouldnt 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 _p18 u32 _s4256 u32 _cbc0, _cbc1 // for cipher block chaining static void hash(const char str, u32 hash5) 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 "AceFish.h" static u32 InitP18 = 0x243f6a88, 0x85a308d3, 0x13198a2e, 0x03707344, 0xa4093822, 0x299f31d0, 0x082efa98, 0xec4e6c89, 0x452821e6, 0x38d01377, 0xbe5466cf, 0x34e90c6c, 0xc0ac29b7, 0xc97c50dd, 0x3f84d5b5, 0xb5470917, 0x9216d5d9, 0x8979fb1b static u32 InitS4256 = 0xd1310ba6, 0x98dfb5ac, 0x2ffd72db, 0xd01adfb7, 0xb8e1afed, 0x6a267e96, 0xba7c9045, 0xf12c7f99, 0x24a19947, 0xb3916cf7, 0x0801f2e2, 0x858efc16, 0x636920d8, 0x71574e69, 0xa458fea3, 0xf4933d7e, 0x0d95748f, 0x728eb658, 0x718bcd58, 0x82154aee, 0x7b54a41d, 0xc25a59b5, 0x9c30d539, 0x2af26013, 0xc5d1b023, 0x286085f0, 0xca417918, 0xb8db38ef, 0x8e79dcb0, 0x603a180e, 0x6c9e0e8b, 0xb01e8a3e, 0xd71577c1, 0xbd314b27, 0x78af2fda, 0x55605c60, 0xe65525f3, 0xaa55ab94, 0x57489862, 0x63e81440, 0x55ca396a, 0x2aab10b6, 0xb4cc5c34, 0x1141e8ce, 0xa15486af, 0x7c72e993, 0xb3ee1411, 0x636fbc2a, 0x2da9c55d, 0x741831f6, 0xce5c3e16, 0x9b87901e, 0xafd6ba33, 0x6c24cf5c, 0x7a325381, 0x28958677, 0x3b8f4898, 0x6b4bb9af, 0xc4bfe81b, 0x66282193, 0x61d809cc, 0xfb21a991, 0x487cac60, 0x5dec8032, 0xef845d5d, 0xe98575b1, 0xdc262302, 0xeb651b88, 0x23893e81, 0xd396acc5, 0x0f6d6ff3, 0x83f44239, 0x2e0b4482, 0xa4842004, 0x69c8f04a, 0x9e1f9b5e, 0x21c66842, 0xf6e96c9a, 0x670c9c61, 0xabd388f0, 0x6a51a0d2, 0xd8542f68, 0x960fa728, 0xab5133a3, 0x6eef0b6c, 0x137a3be4, 0xba3bf050, 0x7efb2a98, 0xa1f1651d, 0x39af0176, 0x66ca593e, 0x82430e88, 0x8cee8619, 0x456f9fb4, 0x7d84a5c3, 0x3b8b5ebe, 0xe06f75d8, 0x85c12073, 0x401a449f, 0x56c16aa6, 0x4ed3aa62, 0x363f7706, 0x1bfedf72, 0x429b023d, 0x37d0d724, 0xd00a1248, 0xdb0fead3, 0x49f1c09b, 0x075372c9, 0x80991b7b, 0x25d479d8, 0xf6e8def7, 0xe3fe501a, 0xb6794c3b, 0x976ce0bd, 0x04c006ba, 0xc1a94fb6, 0x409f60c4, 0x5e5c9ec2, 0x196a2463, 0x68fb6faf, 0x3e6c53b5, 0x1339b2eb, 0x3b52ec6f, 0x6dfc511f, 0x9b30952c, 0xcc814544, 0xaf5ebd09, 0xbee3d004, 0xde334afd, 0x660f2807, 0x192e4bb3, 0xc0cba857, 0x45c8740f, 0xd20b5f39, 0xb9d3fbdb, 0x5579c0bd, 0x1a60320a, 0xd6a100c6, 0x412c7279, 0x679f25fe, 0xfb1fa3cc, 0x8ea5e9f8, 0xdb3222f8, 0x3c7516df, 0xfd616b15, 0x2f501ec8, 0xad0552ab, 0x323db5fa, 0xfd238760, 0x53317b48, 0x3e00df82, 0x9e5c57bb, 0xca6f8ca0, 0x1a87562e, 0xdf1769db, 0xd542a8f6, 0x287effc3, 0xac6732c6, 0x8c4f5573, 0x695b27b0, 0xbbca58c8, 0xe1ffa35d, 0xb8f011a0, 0x10fa3d98, 0xfd2183b8, 0x4afcb56c, 0x2dd1d35b, 0x9a53e479, 0xb6f84565, 0xd28e49bc, 0x4bfb9790, 0xe1ddf2da, 0xa4cb7e33, 0x62fb1341, 0xcee4c6e8, 0xef20cada, 0x36774c01, 0xd07e9efe, 0x2bf11fb4, 0x95dbda4d, 0xae909198, 0xeaad8e71, 0x6b93d5a0, 0xd08ed1d0, 0xafc725e0, 0x8e3c5b2f, 0x8e7594b7, 0x8ff6e2fb, 0xf2122b64, 0xb812, 0x900df01c, 0x4fad5ea0, 0x688fc31c, 0xd1cff191, 0xb3a8c1ad, 0x2f2f2218, 0xbe0e1777, 0xea752dfe, 0x8b021fa1, 0xe5a0cc0f, 0xb56f74e8, 0x18acf3d6, 0xce89e299, 0xb4a84fe0, 0xfd13e0b7, 0x7cc43b81, 0xd2ada8d9, 0x165fa266, 0x80957705, 0x93cc7314, 0x211a1477, 0xe6ad2065, 0x77b5fa86, 0xc75442f5, 0xfb9d35cf, 0xebcdaf0c, 0x7b3e89a0, 0xd6411bd3, 0xae1e7e49, 0x00250e2d, 0x2071b35e, 0x226800bb, 0x57b8e0af, 0x2464369b, 0xf009b91e, 0x5563911d, 0x59dfa6aa, 0x78c14389, 0xd95a537f, 0x207d5ba2, 0x02e5b9c5, 0x83260376, 0x6295cfa9, 0x11c81968, 0x4e734a41, 0xb3472dca, 0x7b14a94a, 0x1b510052, 0x9a532915, 0xd60f573f, 0xbc9bc6e4, 0x2b60a476, 0x81e67400, 0x08ba6fb5, 0x571be91f, 0xf296ec6b, 0x2a0dd915, 0xb6636521, 0xe7b9f9b6, 0xff34052e, 0xc5855664, 0x53b02d5d,
Cryptography-Digest Digest #700
Cryptography-Digest Digest #700, Volume #12 Sun, 17 Sep 00 14:13:01 EDT
Contents:
Re: RSA?? (Simon Johnson)
Re: Double Encryption Illegal? (Paul Schlyter)
Assistance (Teo Li Xi)
Re: Carnivore article in October CACM _Inside_Risks (Jonathan Thornburg)
Re: RC4: Tradeoff key/initialization vector size? ("Scott Fluhrer")
Re: Double Encryption Illegal? (Tom St Denis)
Re: Dangers of using same public key for encryption and signatures? (Simon Johnson)
Re: RC4: Tradeoff key/initialization vector size? (Tom St Denis)
Re: RC4: Tradeoff key/initialization vector size? (Tom St Denis)
Re: Weaknesses in this algorithm? (Tim Tyler)
Re: Serpent S-boxes (again) (Tim Tyler)
Re: Music Industry Offers US$10K for cracking their encryption system (Tim Tyler)
Re: "Secrets and Lies" at 50% off (Tim Tyler)
Re: ExCSS Source Code (David A. Wagner)
Re: Serpent S-boxes (again) (Mack)
Re: Tying Up Loose Ends - Correction (John Savard)
Re: Double Encryption Illegal? (Mok-Kong Shen)
Re: Specially for Dr. mike (with regard to patience, persistence, truth, (John M.
Gamble)
Re: wince encryption algorithm (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Guy Macon)
Re: Weaknesses in this algorithm? (Guy Macon)
Re: Assistance (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
From: Simon Johnson [EMAIL PROTECTED]
Subject: Re: RSA??
Date: Sun, 17 Sep 2000 13:15:24 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (DJohn37050) wrote:
ANSI X9 requires 1024 bit RSA and DSA keys and 161 bit ECC keys.
Don Johnson
Hrm, DSA is a government standard right?
I find it alarming that while the NSA produces conventional algorithms
such as skipjack, it doesn't directly produce new public key algorithm.
I sometimes wonder if all the work of Turing has been released. Prehaps
somewhere in the archives of some government agenicy is a paper which
proves p=np :)
and yes, i'm sprinkling fairydust :)
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: 17 Sep 2000 15:25:39 +0200
In article 8q273q$5aj$[EMAIL PROTECTED],
Tom St Denis [EMAIL PROTECTED] wrote:
In article 8q1tea$bhp$[EMAIL PROTECTED],
[EMAIL PROTECTED] (Paul Schlyter) wrote:
In article 8pvnav$gdt$[EMAIL PROTECTED],
Tom St Denis [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Mok-Kong Shen [EMAIL PROTECTED] wrote:
PRdO wrote:
IMHO double encryption *does not* add security, i.e., double
encryption in 128-bit doesn't equal better encryption.
(since encryption uses random keys, "randoming" again the data
would not lead to more secure data).
If you have an algorithm that does a perfect job (do
you happen to have one?), then there is by definition
nothing to improve. Otherwise, multiple encryption may
help, if done properly.
Ah but double encryption is not the way to go about it.
So you're claiming that triple-DES is no more secure than single-
DES ???
Read my message. Geez. I said "double" encryption is not the way to
go about added security.
But you believe "triple" encryption is, since you don't think your
statement applied to triple-DES?
==
One cannot generally state that multiple encryption enhances, or does
not enhance, security -- it depends a lot on the encryption used.
Consider for instance the good ol' Caesar cipher: applying it
multiple times with different "keys" makes the final encryption no
safer than if it was applied only once with one single "key".
Now, instead consider DES, where applying it three times does indeed
make tne encryption safer than if applied only once -- that's why
3DES is so popular.
--
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se orpaul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pauschhttp://welcome.to/pausch
--
From: Teo Li Xi [EMAIL PROTECTED]
Subject: Assistance
Date: Sun, 17 Sep 2000 22:30:09 +0800
Dear all:
Does anyone here have any experience with implementing Wei Dai's
Crypto++ library in Microsoft Visual C++ 6 environment? I need to use
some of the algorithms in there like DES/IDEA/RSA.
Regards,
jon
--
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Carnivore article in October CACM _Inside_Risks
Date: 17 Sep 2000 16:35:00 +0200
In article [EMAIL PROTECTED],
Douglas A. Gwyn [EMAIL PROTECTED] asked
Should we require
Cryptography-Digest Digest #701
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
Cryptography-Digest Digest #702
Cryptography-Digest Digest #702, Volume #12 Sun, 17 Sep 00 17:13:00 EDT Contents: Re: Killer aircraft to fly again? (Mok-Kong Shen) Re: Lossless compression defeats watermarks (Scott Craver) S-Boxes (Anonymous) wince encryption algorithm (Nomen Nescio) Re: SDMI Crypto Challenge (Scott Craver) Re: question about delastelle cipher in Bauer's book (Mok-Kong Shen) Bugs 3.4.0 and Bcrypt 2.0 : Open Source and Multiplateform (Sylvain Martinez) From: Mok-Kong Shen [EMAIL PROTECTED] Crossposted-To: sci.military.naval,alt.conspiracy,sci.geo.earthquakes Subject: Re: Killer aircraft to fly again? Date: Sun, 17 Sep 2000 21:30:38 +0200 [EMAIL PROTECTED] wrote: [snip] Please kindly don't cross-post to sci.crypt stuffs that have nothing to do with cryptology. Thanks. M. K. Shen -- From: [EMAIL PROTECTED] (Scott Craver) Subject: Re: Lossless compression defeats watermarks Date: 17 Sep 2000 19:56:09 GMT Matthew Skala [EMAIL PROTECTED] wrote: If a watermarking scheme works perfectly (in the sense of being inmperceptible by humans) and a lossy compression scheme works perfectly (in the sense of maximizing compression without harming perceptual quality) then compressing and decompressing a signal will have the effect of removing the watermark. On the other hand, we have Ross Anderson and Fabien Petitcolas's observation: if perfect compression existed, then we would still have steganography. Simply take any string of encrypted text and feed it into the Perfect Image Decompressor. Mail the output to your friend. Thus, the watermark will necessarily be in the part of the signal that is thrown out by the lossy compression. Well, if the compression is truly perfect, maybe. But this will not happen. Also, there are lots of "channels" in an image which are often imperceptible by users but off-limits to any fair compression algorithm. Perceptible but arbitrary. For instance, using Photoshop to add a very subtle, continuous spatial deformation to a part of the image. Of the original image I and deformed image D, no algorithm can tell which is the "right" one, unless the image is something fragile to deformations (like a grid of black and white pixels.) A compression scheme could not "undo" your deformation, nor compress I and D to the same thing. Going in the other direction, if you have a watermarking scheme that survives lossy compression, then that implies some deficiency in either the watermarking scheme or the lossy compression or both: either the watermark is altering the perceptible part of the signal, or the lossy compression is transmitting some imperceptible information. Certain aspects of the image are technically perceptible, especially in comparison to the original, but unimportant enough to be effectively ignored by the viewer. In fact, the pioneering work of Cox et al consisted of tweaking low-frequency NxN DCT coefficients of an NxN image. This has the appearance of overlaying a kind of transparent, smooth gauzy stuff to the image, which is "perceptible enough" to survive all manner of compression. You can't see it w/o comparison to the original. When I was working on a watermarking article, a professor dropped by my cube (I was working at Intel, he on sabbatical) and I showed him an illustration of 3 images, one unmarked and one with a low-freq DCT mark. "It looks like clouds," he said. It turned out he was relaxing his eyes, the way you look at stereograms, to superimpose the two; a trick he learned when studying the effects of image compression. The success of watermarking schemes, in a world of lossy compression, depends upon either the user's willingness to accept signal degradation, or the deficiencies of the lossy compression at removing spurious data. Heh heh. The success of watermarking depends on more than that. Compression is no big deal; the problem is the 500 bazillion different ways one can subtly alter an image in Photoshop. Nothing is robust to them all. -- Matthew Skala -S -- Date: Sun, 17 Sep 2000 22:04:02 +0200 From: Anonymous [EMAIL PROTECTED] Subject: S-Boxes Sorry for me newbie question. What are S-Boxes? What are they used for and how are they built? -- From: Nomen Nescio [EMAIL PROTECTED] Subject: wince encryption algorithm Date: Sun, 17 Sep 2000 22:10:10 +0200 (CEST) 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
Cryptography-Digest Digest #703
Cryptography-Digest Digest #703, Volume #12 Sun, 17 Sep 00 22:13:01 EDT
Contents:
Re: Dangers of using same public key for encryption and signatures? ("Brian Gladman")
Re: Killer aircraft to fly again? (Ogden Johnson III)
Re: Assistance (David A Molnar)
Re: winace encryption algorithm (David A Molnar)
Re: Killer aircraft to fly again? (Ross Smith)
Re: Lossless compression defeats watermarks ("Paul Pires")
Frequency Analysis Tables ("SafeMode")
Re: SDMI Crypto Challenge ("Paul Pires")
Re: ExCSS Source Code (David A Molnar)
A Degree in Encryption ("Nasser Ismaily")
Re: wince encryption algorithm (An Metet)
Re: Killer aircraft to fly again? (Brian Allardice)
Re: S-Boxes ("Douglas A. Gwyn")
wince encryption algorithm (No User)
From: "Brian Gladman" [EMAIL PROTECTED]
Subject: Re: Dangers of using same public key for encryption and signatures?
Date: Sun, 17 Sep 2000 22:29:44 +0100
"Simon Johnson" [EMAIL PROTECTED] wrote in message
news:8q2mo8$lb7$[EMAIL PROTECTED]...
These laws are written by ignorant people for ignorant people. Since
the one-time pad is unbreakable, it lends itself to this situation. Say
the ask for the keys to some file. You xor a non-incriminating plain-
text with the encrypted file to retreive a 'pseudo-one-time-pad key'
You the surrender this as the key.
They can't prove the key is incorrect without lauching an attack on the
underlying encryption algorithm. Which is probably impossible.
I agree - this and many other probelms with this legislation were pointed
out during its passage through Parliament but the UK government would not
listen.
Brian Gladman
--
From: Ogden Johnson III [EMAIL PROTECTED]
Crossposted-To: sci.military.naval,alt.conspiracy,sci.geo.earthquakes
Subject: Re: Killer aircraft to fly again?
Date: Sun, 17 Sep 2000 21:53:56 GMT
Mok-Kong Shen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
[snip]
Please kindly don't cross-post to sci.crypt stuffs
that have nothing to do with cryptology. Thanks.
M. K. Shen
And why, pray tell, should sci.crypt be exempt from its fair share of
Usenet kooks?
OJ III
--
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: Assistance
Date: 17 Sep 2000 21:38:29 GMT
Teo Li Xi [EMAIL PROTECTED] wrote:
Dear all:
Does anyone here have any experience with implementing Wei Dai's
Crypto++ library in Microsoft Visual C++ 6 environment? I need to use
some of the algorithms in there like DES/IDEA/RSA.
If my memory serves, Crypto++ comes with a Makefile. Opening this with VC++ creates a
project and can successfully build the library. Do a MSDN search on "makefile" and
dealing with projects
with makefiles and you should be almost there.
-David
--
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: winace encryption algorithm
Date: 17 Sep 2000 21:39:30 GMT
Mok-Kong Shen [EMAIL PROTECTED] wrote:
No User wrote:
[snip]
You posted doubled. I have sent follow-up to the original
thread.
He's likely sending several posts via indepdendent chains of anonymous remailers,
on the assumption that at least one of the chains will fail. Which, sadly, is an
all too fair assumption.
-David
--
From: Ross Smith [EMAIL PROTECTED]
Crossposted-To: sci.military.naval,alt.conspiracy,sci.geo.earthquakes
Subject: Re: Killer aircraft to fly again?
Date: Mon, 18 Sep 2000 10:10:14 +1200
Ogden Johnson III wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
[snip]
Please kindly don't cross-post to sci.crypt stuffs
that have nothing to do with cryptology. Thanks.
M. K. Shen
And why, pray tell, should sci.crypt be exempt from its fair share of
Usenet kooks?
Because it already *has* its fair share of Usenet kooks. If we get any
more, we'll be over quota and get complaints from Immigration.
--
Ross Smith [EMAIL PROTECTED] The Internet Group, Auckland, New Zealand
"C++ is to programming as sex is to reproduction. Better ways might
technically exist but they're not nearly as much fun." -- Nikolai Irgens
--
From: "Paul Pires" [EMAIL PROTECTED]
Subject: Re: Lossless compression defeats watermarks
Date: Sun, 17 Sep 2000 15:43:30 -0700
snip
The success of watermarking schemes, in a world of lossy compression,
depends upon either the user's willingness to accept signal degradation,
or the deficiencies of the lossy compression at removing spurious data.
It is only spurious if the watermark generating method is kept secret right?
The contest is set up with nothing but content and no method published right?
Why should anyone be interested in this exercise since it simply restates a
known.
Steganography can be relatively secure if the underlying method is kept secret.
If it
Cryptography-Digest Digest #704
Cryptography-Digest Digest #704, Volume #12 Mon, 18 Sep 00 00:13:01 EDT Contents: Re: A Degree in Encryption (Mack) Re: Serpent S-boxes (again) (Mack) Re: Tying Up Loose Ends - Correction (John Savard) Re: Tying Up Loose Ends - Correction (John Savard) Re: Tying Up Loose Ends - Correction (John Savard) Re: question about delastelle cipher in Bauer's book (John Savard) Re: Serpent S-boxes (again) (Terry Ritter) Re: Serpent S-boxes (again) (Tom St Denis) Re: SDMI Crypto Challenge (Tom St Denis) Re: One-way encryption (Tom St Denis) Re: Music Industry Offers US$10K for cracking their encryption system (Tom St Denis) Re: A Degree in Encryption (David A Molnar) From: [EMAIL PROTECTED] (Mack) Subject: Re: A Degree in Encryption Date: 18 Sep 2000 01:28:23 GMT Hi I am looking for info as to what is the best, or proper university to enroll for a phd in encryption. I have a degree in computer engineering and currently working on MBA. I also have a ten yr working experience. Any help on this will be highly appreciated. Best Regards You have a pretty good choice of fields to get a degree in. Number Theory, Information Science, Information Theory ... But I don't know of a university that offers a degree program specifically in encryption. Mack Remove njunk123 from name to reply by e-mail -- From: [EMAIL PROTECTED] (Mack) Date: 18 Sep 2000 01:48:56 GMT Subject: Re: Serpent S-boxes (again) 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." The idea of non-linearity is pretty straight forward but the specific phrase "a non-linearity of four" is ambiguous. Does it mean minimum maximum or mean. In this case I believe it is minimum distance to the set of affine functions. It could also mean the sum of distances to affine funtions as has been used in the past. 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. That is indeed the most common measure. But there are other measures. Most of the differences are restricted to the case of the nonlinearity of s-boxes as opposed to individual functions. I personally use the minimum hamming distance to the set of affine functions. (Rueppel's critera). This is easy to compute and relatively fast. Unless there is a reason to use a more complicated implementation I generally stick to that for computer programming. The WHT is much better for algebraic analysis. Did you receive the list of Citations that I sent you via e-mail? --- Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Mack Remove njunk123 from name to reply by e-mail -- From: [EMAIL PROTECTED] (John Savard) Subject: Re: Tying Up Loose Ends - Correction Date: Mon, 18 Sep 2000 01:39:22 GMT On Sun, 17 Sep 2000 19:34:06 +0200, Mok-Kong Shen [EMAIL PROTECTED] wrote, in part: I don't think that it is worthwhile to worry about the slight 'increase in redundancy'. My position is a bit different. I agree that it isn't so important as to be *the* _sine qua non_ of good cryptography. However, when known plaintext is not available, redundancy is what the cryptanalyst has to grab on to. So the payoff from a reduction in redundancy might be a significant reduction in the
