Cryptography-Digest Digest #214, Volume #12 Wed, 12 Jul 00 18:13:00 EDT
Contents:
Re: SafeIT - Untrusted encryption program. (Sundial Services)
Re: Any crypto jokes? (potentially OT) (Sundial Services)
Re: Newbie Question (long-ish) (Stephen Hui)
Efficient Arithmetic Coding ("Kai Volkenand")
Re: RC4-- repetition length? (John Myre)
Re: cray and time needed to attack (Stanley Chow)
Re: Posting downside up (Re: Steganographic encryption system) (Garry Knight)
Re: Newbie Question (long-ish) ("Joseph Ashwood")
Re: Efficient Arithmetic Coding ("Joseph Ashwood")
Re: Questions!!!! (Mark Wooding)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Efficient Arithmetic Coding (SCOTT19U.ZIP_GUY)
Re: Proposal of some processor instructions for cryptographical (Iain McClatchie)
Re: DES Analytic Crack (Mok-Kong Shen)
Re: attack against CBC mode (Mok-Kong Shen)
Re: Q: Hadamard transform (Mok-Kong Shen)
Re: Efficient Arithmetic Coding (Helger Lipmaa)
Re: Efficient Arithmetic Coding (Helger Lipmaa)
----------------------------------------------------------------------------
Date: Wed, 12 Jul 2000 12:14:28 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: SafeIT - Untrusted encryption program.
Well, to be fair to this particular entrepreneur, "almost anything is
better than a postcard," and for much of the e-mail that is sent in this
world, tough security might be an overkill. Still, I think it will
prove to be important to the success of SafeIT that they -do- publish
the algorithm used.
A tool like SafeIT would need to sell itself on its convenience to the
end-user for the applications intended ... and its price and simplicity
... not necessarily on its ability to withstand the NSA or MI-5. But in
order to do that, it must first withstand the "snake oil attack" by
publishing its algorithm. The product might be viable (I don't know, I
haven't used it) even if its algorithm is not cryptographically bullet
proof.
>Mark Wooding wrote:
> This one looks like a candidate for the Crypto-Gram doghouse.
>
> > I hope they dare to publish their algorithm to the public.
> >Othervice, I hope someone else does.
>
> Quite so.
>
==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
------------------------------
Date: Wed, 12 Jul 2000 12:20:15 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Any crypto jokes? (potentially OT)
Douglas A. Gwyn wrote:
>
> rosi wrote:
> > [snip]
>
> Thanks, that was one of the biggest jokes yet.
If Rosi ever runs out of work as a cryptographer, there's a world
awaiting on the lecture circuit ... just write a book. Or maybe go into
politics and start writing laws. ;-)
------------------------------
From: Stephen Hui <[EMAIL PROTECTED]>
Subject: Re: Newbie Question (long-ish)
Date: Wed, 12 Jul 2000 14:38:10 -0500
Joseph Ashwood wrote:
>
> Actually this is in the FAQ. Basically the general concensus is that if your
> program needs to remain secure to make the cipher secure, then your cipher
> is not secure. Your software will be broken (see any warez site for
> reference), your code will be known, and your security will never have
> existed. So we would prefer you don't post your ciphertect here unless you
> have an algorithm to go with it.
> Joe
>
Duly noted; thanks. BTW, is there a URL or some other resource for the
FAQ? I'd like to look over it.
I'll think some more about my algorithm. Maybe there is a way to make
it more secure....
In fact, maybe someone can offer some ideas. I developed this algorithm
three years ago, right after my freshman year of college (I'm now a
5th-year senior in Computer Science). Here's the general idea of my
algorithm (mind you, I haven't had any formal training in cryptography
or anything of that sort, but that's about to change in about six weeks
when classes start up again):
It was originally designed to be a one-way hash, but in the latest
revision, I decided to try to make it two-way. It's the two-way feature
that makes it insecure.
[Note: When I mention "xor-ing letters", I mean xor-ing the letters'
ASCII codes.]
I can't remember the exact algorithm from the original design, but in
general, it computed two keys based on the string (typically a password)
that it is given. Then it goes through the string letter by letter,
xor-ing the first key with even-indexed letters (suppose the string is
represented as an array of characters) and xor-ing the second key with
the odd-indexed letters. Then the ASCII code of the encrypted letter is
shifted into the special-characters region of the ASCII codes (meaning
an integer is added to the ASCII code of the encrypted character to
yield a character that is not alpha-numeric, e.g. the console "graphics"
characters). This is to keep the password file non-human-readable.
There was a way to actually *encrypt* the key into the ciphertext, but I
can't remember how that was accomplished.
I did this to try to prevent a one-to-one mapping from plaintext letters
to ciphertext letters. Any one letter would have to always fall into an
even- or odd-index for this one-to-one mapping to occur.
In the latest incantation, a two-way version of the algorithm, the
unencrypted keys are prepended to the encrypted string. So it only
works if the attacker doesn't know the algorithm.
Each plaintext letter is still xor-ed with a key, but now, it's xor-ed
with two keys. A string of letters is randomly generated (any length),
and each adjacent pair of letters in the random string forms the two
keys. For example, if my plaintext string is "text", and my random
letter string is "dhvg", then the possible pairs of letters from the key
string are dh, hv,vg, gd, dh, hv.... So each letter in the plaintext
("text") is xor-ed:
"t" ^ "d" ^ "h" = encrypted "t"
"e" ^ "h" ^ "v" = encrypted "e"
...
If more random letters are used, the algorithm can map more ciphertext
letters from a plaintext letter.
It's not an effective hash since the keys are generated randomly, but
prepending the random string to the ciphertext string allows the
ciphertext to be decrypted easily because the algorithm (or attacker)
can know where and how long the random string is.
These algorithms are essentially letter-replacement, but a little more
complex than the standard cereal-box-decoder-ring.
Am I sort of on track, or am I totally out in deep roving left field?
If anyone needs source code, I can provide sources for both (the first
version is in Pascal and the second is in Perl5). Any ideas or comments
will be greatly appreciated. I'm totally open any ideas.
Thanks!
Stephen.
------------------------------
From: "Kai Volkenand" <[EMAIL PROTECTED]>
Subject: Efficient Arithmetic Coding
Date: Wed, 12 Jul 2000 21:47:56 +0200
Does anybody knows about an good implementation
in C or C++?
Thanx
[EMAIL PROTECTED]
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Wed, 12 Jul 2000 14:16:58 -0600
Bill Unruh wrote:
<snip>
>
> Since 16^2*16!= 10^16, your cycles must all have been much much shorter
> than that!. Has any work been done on analysing the cycles of RC4?
RSA did a lot of analysis, but declines to make it public (at least,
the last I know of). Somewhere at their site there may be more
recent information.
> Is
> there some way of changing it to ensure that there is only one cylce of
> max length?
I don't know, but my intuition tells me "no, at least not without
major rework." And of course, even minor rework will usually
invalidate prior analysis. Somebody smarter than me would have
to find this question interesting enough to work on; I can't see
where to start.
It would be interesting to see RSA's analysis of cycle lengths.
What guarantees on minimum cycle length are there? What are the
statistics on expected cycle lengths? And so forth. From a
practical point of view, we don't need maximal length, just
very long. And with 256^2 x 256! states, there is sure a lot
of room.
JM
------------------------------
From: Stanley Chow <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Wed, 12 Jul 2000 20:43:03 GMT
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > I am not sure what she said, but a foot per second is a very good
> > approximation of C (speed of light in vacuum).
>
> I'm sure this was a typo -- you meant "nanosecond" instead of
> "second."
Yes, exactly what I meant. Thanks.
This will teach me to be nit-picker - check your arithmatic, then
carefully proof-read.
--
Stanley Chow VP Engineering [EMAIL PROTECTED]
Cloakware Corp (613) 271-9446 x 223
------------------------------
From: [EMAIL PROTECTED] (Garry Knight)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Posting downside up (Re: Steganographic encryption system)
Date: Wed, 12 Jul 2000 21:52:45 +0100
Reply-To: [EMAIL PROTECTED]
In article <+7F*[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>This is probably a product of braindead if right-way-up quoting; people
>who produce stuff like
>
>A wrote
>>B wrote
>>>C wrote
>>>>[C's article unsnipped]
>>>[B's article unsnipped]
>>[A's article unsnipped]
You left out the
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Of all the characters in all the character sets on all the servers in
all the world, this one most be the most used. In fact, I would guess
that it takes up half the disk space on the microsoft news servers.
--
Garry Knight
[EMAIL PROTECTED]
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Newbie Question (long-ish)
Date: Wed, 12 Jul 2000 14:26:19 -0700
>From your description it seems to fall rather easily into the category of
stream cipher (with a few minor changes). These are usually very similar to
(in functional pseudo-code):
BIT gen_rand()
{
do something to create a random byte
}
BIT encryptOneByte(BIT input)
{
return (gen_rand() XOR input)
}
Of course they typically operate on bytes not bits, but as a minimal
expression it's quite simple. And the security relies completely in the
security of gen_rand, which can be analyzed many different ways. By now
you've probably gone through linear algebra (probably a year or 2 ago) so as
a very basic test try to solve your gen_rand function, attempt to solve for
the algebraic equation for your rng outputs, if you can find one that is
small enough to be written your algorithm is certainly weak (think Gaussian
elimination, and the time it would take). If there does not exist an
expression of your random number generator of size less than 2^80 there's a
chance it might be secure. You also need to remember that there are many
different algebraic spaces in which you random number generator could be
written.
Joe
"Stephen Hui" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
> >
> > Actually this is in the FAQ. Basically the general concensus is that if
your
> > program needs to remain secure to make the cipher secure, then your
cipher
> > is not secure. Your software will be broken (see any warez site for
> > reference), your code will be known, and your security will never have
> > existed. So we would prefer you don't post your ciphertect here unless
you
> > have an algorithm to go with it.
> > Joe
> >
>
>
> Duly noted; thanks. BTW, is there a URL or some other resource for the
> FAQ? I'd like to look over it.
>
> I'll think some more about my algorithm. Maybe there is a way to make
> it more secure....
>
> In fact, maybe someone can offer some ideas. I developed this algorithm
> three years ago, right after my freshman year of college (I'm now a
> 5th-year senior in Computer Science). Here's the general idea of my
> algorithm (mind you, I haven't had any formal training in cryptography
> or anything of that sort, but that's about to change in about six weeks
> when classes start up again):
>
> It was originally designed to be a one-way hash, but in the latest
> revision, I decided to try to make it two-way. It's the two-way feature
> that makes it insecure.
>
> [Note: When I mention "xor-ing letters", I mean xor-ing the letters'
> ASCII codes.]
>
> I can't remember the exact algorithm from the original design, but in
> general, it computed two keys based on the string (typically a password)
> that it is given. Then it goes through the string letter by letter,
> xor-ing the first key with even-indexed letters (suppose the string is
> represented as an array of characters) and xor-ing the second key with
> the odd-indexed letters. Then the ASCII code of the encrypted letter is
> shifted into the special-characters region of the ASCII codes (meaning
> an integer is added to the ASCII code of the encrypted character to
> yield a character that is not alpha-numeric, e.g. the console "graphics"
> characters). This is to keep the password file non-human-readable.
> There was a way to actually *encrypt* the key into the ciphertext, but I
> can't remember how that was accomplished.
>
> I did this to try to prevent a one-to-one mapping from plaintext letters
> to ciphertext letters. Any one letter would have to always fall into an
> even- or odd-index for this one-to-one mapping to occur.
>
> In the latest incantation, a two-way version of the algorithm, the
> unencrypted keys are prepended to the encrypted string. So it only
> works if the attacker doesn't know the algorithm.
>
> Each plaintext letter is still xor-ed with a key, but now, it's xor-ed
> with two keys. A string of letters is randomly generated (any length),
> and each adjacent pair of letters in the random string forms the two
> keys. For example, if my plaintext string is "text", and my random
> letter string is "dhvg", then the possible pairs of letters from the key
> string are dh, hv,vg, gd, dh, hv.... So each letter in the plaintext
> ("text") is xor-ed:
>
> "t" ^ "d" ^ "h" = encrypted "t"
> "e" ^ "h" ^ "v" = encrypted "e"
> ...
>
> If more random letters are used, the algorithm can map more ciphertext
> letters from a plaintext letter.
>
> It's not an effective hash since the keys are generated randomly, but
> prepending the random string to the ciphertext string allows the
> ciphertext to be decrypted easily because the algorithm (or attacker)
> can know where and how long the random string is.
>
> These algorithms are essentially letter-replacement, but a little more
> complex than the standard cereal-box-decoder-ring.
>
> Am I sort of on track, or am I totally out in deep roving left field?
> If anyone needs source code, I can provide sources for both (the first
> version is in Pascal and the second is in Perl5). Any ideas or comments
> will be greatly appreciated. I'm totally open any ideas.
>
> Thanks!
> Stephen.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Efficient Arithmetic Coding
Date: Wed, 12 Jul 2000 14:27:56 -0700
Assuming you mean for dealing with large integers/reals. I'd recommend
Miracl (http://indigo.ie/~mscott/) If you're looking for something else,
you'll have to be more specific.
Joe
> Does anybody knows about an good implementation
> in C or C++?
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Questions!!!!
Date: 12 Jul 2000 21:21:41 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
> If memory serves, I think that there is an additional requirement for
> the impossible differential to hold -- I think the round function must
> be bijective.
Ahh. That explains why my simulation didn't work, then: it was
generating possibly nonbijective functions.
OK. This doesn't actually apply to Luby-Rackoff ciphers with more than
three rounds, then.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 12 Jul 2000 21:45:04 +0100
Reply-To: [EMAIL PROTECTED]
On Wed, 12 Jul 2000 02:51:16 +0100, Michael Rozdoba <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> phil hunt <[EMAIL PROTECTED]> wrote:
>> Got it in one. I imagine there's other benefits as well, but not having
>> a background in cryptography, I wouldn't know what they are.
>
>Any idea when you might have some code for us to play with?
About the weekend, I expect.
> I'm very
>interested in what you have planned. I quite fancy the idea of encrypting
>my entire music collection, just to provide secure space for potentially
>locating data - as I was about to mp3 it anyway (*)
>
>Hmm, I wonder, given the law want to be able to argue, if one has
>encrypted data & won't release the key then one is guilty of something,
>would they be equally keen on reasoning if one has encrypted data that
>decrypts to non-sensitive information, that there must be further
>sensitive information there? That doesn't seem to be so big a step (from
>their point of view).
>
>As a newbie to linux, how easy will it be to extract files & then pass
>them on to another process (such as a thumbnail viewer, mp3 player etc),
>guaranteeing that the data doesn't pass through storage on disc in an
>unencrypted state?
Reasonably easy; you could use a pipe, for example, provided that both programs
support it. Another way would be to use a ramdisk (is there a ramdisk filing
system for Linux).
A third way, and this is a long term aim of stes, would be to allow stes
to use the NFS protocol to pretend to be a network filing system.
(Of course, none of these methods is secure if someone else has root on
your PC).
>Can a program, that doesn't know it's handling sensitive data, be wrapped
>up in such a way that it is protected from doing anything undesirable with
>that data? A naive approach would be a mechanism to only permit it access
>to files in memory, but that could require huge amounts of memory.
Modern PCs have 64-128M of memory, which is plenty for many applications.
>Some
>method to allow access to the virtual data, with decrypted data stored in
>a cache in memory, would be more practical.
Like a ramdisk.
>(*) a minor question: can a zero length file be encrypted, merely to
>ensure a key is present in the data for subsequent use?
Yes.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 12 Jul 2000 21:46:28 +0100
Reply-To: [EMAIL PROTECTED]
On Wed, 12 Jul 2000 00:40:39 -0400, jungle <[EMAIL PROTECTED]> wrote:
>current, well working stego have ration of 1 to 2 ...
>and all are super safe / super stego ...
>you are creating stego that will have ratio of 1 to 30 ...
>
>what a waste of resources ...
I'm not forcing you to use it, you know.
BTW, have you ever heard of "traffic analysis"?
BTW2, you are quoting upside down.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 12 Jul 2000 21:51:13 +0100
Reply-To: [EMAIL PROTECTED]
On Wed, 12 Jul 2000 04:02:56 +0100, Michael Rozdoba <[EMAIL PROTECTED]> wrote:
>In article
><[EMAIL PROTECTED]>, phil hunt
><[EMAIL PROTECTED]> wrote:
>> This is infact what blowfish does (I've just checked it). But I thought
>> blowfish was a strong cipher? -- obviously I must be wrong somewhere
>> here.
>
>Surely that depends on the definition of strong? If it merely means hard
>to decrypt without the key, that doesn't contradict the statement that the
>encrypted data is recognisable as encrypted data.
Well, it seems to me that "strong" means that no-one can proctically find
out any useful information about the plaintext if they know the ciphertext
(obviously the size of the ciphertext file places a maximum limit on
the complexity of the plaintext, but that should be it).
If you can tell that the plaintext contains repeated blocks, that could
help an adversary.
>> So how do I get it so it doesn't repeat?
>
>Do you need to? You were going to rely on the source being public to prove
>it extends filesizes & thus a 25KB cipher text might legitimately only
>contain a 1KB plain text. Would this not still work, as long as the
>remaining data is not noise, but rather, is encrypted noise?
I want the program to be as strong as possible, to give away as little
as possible.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Efficient Arithmetic Coding
Date: 12 Jul 2000 21:36:05 GMT
[EMAIL PROTECTED] (Joseph Ashwood) wrote in <e0zRbgE7$GA.77@cpmsnbbsa08>:
>Assuming you mean for dealing with large integers/reals. I'd recommend
>Miracl (http://indigo.ie/~mscott/) If you're looking for something else,
>you'll have to be more specific.
> Joe
>> Does anybody knows about an good implementation
>> in C or C++?
>
>
>
If you look at my compression page it has a pointer
to Matts. Which is good in the sense that it compresses
with out gaps. It compresses to the complete set of possible
binary files and is totally bijetive as far as I can tell.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: Iain McClatchie <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Wed, 12 Jul 2000 14:39:50 -0700
Eric> Cray vector systems have implemented a "bit matrix multiply" for
Eric> many years.
I looked at implementing this in a high-end MIPS processor in 1996.
Since I didn't want to extend the register set state to more than
64x32 bits, I couldn't multiple a 64x64 bit matrix by a 64x1 vector
because I couldn't get all the state into the CPU core.
Instead, I figured I could do an 8x8 bit by 8x8 bit matrix
multiply-accumulate. This fit nicely into the existing register
model. Unfortunately, it does 512 ANDs per instruction, versus the
4096 ANDs necessary for each 64x64 x 64x1 multiply, so it's slower.
Yah, you can block the matrix multiply like you do for linear
algebra, but you really need more state in the core and we didn't
have it.
To make up the speed difference, we would have had to go for bigger
registers, like AltiVec eventually did. We fumbled around with this
idea for a while but could never get it to gel. In retrospect, the
AltiVec team did a pretty good job, and I think the Imagine folks
at Stanford have found a really useful paradigm.
We were bumming about this until I took a look at the sample
(unclassified) code the NSA suggested could be sped up by bit matrix
multiply. They were using the BMM to seperate a bitstream composed
of interleaved 5 and 6 bit fields into the two component bitstreams.
A MIPS processor just rips through this with ordinary shifts and
masks, and so there is no justification at all for BMM.
After a few more glimpses like this (for instance, their insistence
that their algorithms don't cache) I figured that the NSA wasn't
actually doing much encryption/decryption work with their computers,
but rather used that as a cover for whatever they were actually doing
with them. I find it somewhat amusing then that all the work that
Cray put into supporting encryption ops in $30M computers probably
only helped a few researchers in some corner of the NSA, while the
rest of that organization was busy cranking on Cray's I/O
capabilities.
-Iain McClatchie 650-364-0520 voice
http://www.10xinc.com 650-364-0530 FAX
[EMAIL PROTECTED] 650-906-8832 cell
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DES Analytic Crack
Date: Wed, 12 Jul 2000 23:52:06 +0200
"Douglas A. Gwyn" wrote:
> [snip]
>
> I don't think I said earlier, but obviously these expressions are
> most effectively handled in a data structure similar to a parse
> tree as used in implementing programming languages.
It seems that it could be advantageous to first try the diverse ideas
out on a miniature version of DES to gain experiences of which
methods are the best. For the full-scale treatment of DES or a similar
cipher, probably the possibility of employing specially designed
hardware should not be neglected. I imagine that maybe some part
of the mathematics could be turned into hardware modules.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: attack against CBC mode
Date: Wed, 12 Jul 2000 23:52:20 +0200
Serge Vaudenay wrote:
> In order to thwart the attack:
> - encrypt truly random data (e.g. compressed messages),
> - or limit the plaintext size (and change the key),
> - or use 128-bit message blocks (with AES?),
> - or replace the CBC mode (be aware that other famous modes have
> similar weaknesses).
I recently proposed to use the square of sum of all previous plaintext
and ciphertext blocks (addition mod 2^n) as chaining value. That's
non-linear and should be safe against your attack, I suppose.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Hadamard transform
Date: Wed, 12 Jul 2000 23:52:14 +0200
Tim Tyler wrote:
> One thing to note is (I believe) that the linearity properties of the
> Fourier Transform mean that the order of application is of little
> relevance. This may not be so for other transforms.
One maybe odd question I would like to know is whether one
would get something inherently different in quality, if, instead of
doing 1-D Hadamard transform of n^2 values, one fills these
into a matrix of n*n and process that with a 2-D transform.
M. K. Shen
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Efficient Arithmetic Coding
Date: Wed, 12 Jul 2000 23:54:42 +0300
Kai Volkenand wrote:
> Does anybody knows about an good implementation
> in C or C++?
http://www.cs.toronto.edu/~radford/ac.software.html
I once happened to write an AC implementation in PHT, using roughly the
same algorithm.
Helger
http://www.tcm.hut.fi/~helger
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Efficient Arithmetic Coding
Date: Wed, 12 Jul 2000 23:55:54 +0300
Helger Lipmaa wrote:
>
> I once happened to write an AC implementation in PHT, using roughly the
> same algorithm.
Make it to be PHP. PHP3, to be precise.
> Helger
> http://www.tcm.hut.fi/~helger
------------------------------
** 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
******************************
