Cryptography-Digest Digest #881, Volume #9 Wed, 14 Jul 99 14:13:02 EDT
Contents:
Re: Arguement for 'Stream Cipher ~ PRNG' (Mok-Kong Shen)
Re: How Big is a Byte? (was: New Encryption Product!) (Giles Todd)
Re: Differences in binary-based conversions. ([EMAIL PROTECTED])
Re: I wonder why he wrote it that way. (John Savard)
Re: Differences in binary-based conversions. (wtshaw)
Re: Canadian Crypto (John Savard)
Re: Funny News (fungus)
Re: Funny News (fungus)
Re: Replacing IDEA with Blowfish ([EMAIL PROTECTED])
Re: How Big is a Byte? (was: New Encryption Product!) ("donald tees")
Re: Why this simmetric algorithm is not good? (Gabriel Belingueres)
Open source (e.g. GPL) banking project ([EMAIL PROTECTED])
Re: CIA'KRYPTOS is cracked (Derek Bell)
Re: Electronically Exporting crypto source (legally) ("Douglas A. Gwyn")
Why public key in PGP ([EMAIL PROTECTED])
wincrypt.h ([EMAIL PROTECTED])
Music on CD - Great for around the house or dinner (Philip Kappaz)
Re: Why this simmetric algorithm is not good? (Gabriel Belingueres)
Re: How Big is a Byte? (was: New Encryption Product!) (Natarajan Krishnaswami)
Re: Canadian Crypto (Doug Stell)
Re: Problems with the RC4 algorithm (Doug Stell)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Arguement for 'Stream Cipher ~ PRNG'
Date: Wed, 14 Jul 1999 15:21:25 +0200
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Please elaborate a bit more. I can't capture your sentence. Thanks.
>
> Sorry, no problem.
>
> What I am saying is that any stream cipher should be able to encrypt a
> repeating sequence of plaintexts (bits or bytes does not matter), and
> one would expect the ciphertext to be completely pseudo-random to an
> onlooker. Does that makes sense? (I hope...).
>
> For example if the input was 'AAAA' for a stream cipher we could say
> the output was 'abcd'. In a block cipher the output will always
> be 'BBBB' (pretend A is one block) and thus does not form a good PRNG
> in this manner.
>
> Under this argument a streamcipher should make a good PRNG. If it
> makes a good PRNG what is to say it's not a PRNG? Pretend xor'ing the
> output of a LFSR with zero, you know the output will always be the
> output of the LFSR. Now pretend you have some other PRNG source (or
> keystream generator) and you xor it with zero...
>
> Does this make sense?
I was having difficulty with 'time-based permutation', for which
I couldn't even yet have an approprite interpretation. (A permutation
is just that, it doesn't get old with time.)
As to the above, I suppose that one issue involved is the period length
of the keystream. If the period were suitably short, you could get
in the above 'BBBB' with the stream cipher as well. That's why I have
attempted to design a compound PRNG whose period could be practically
arbitrarily large.
M. K. Shen
========================
http://www.stud.uni-muenchen.de/~mok-kong.shen/ (Updated: 12 Apr 99)
------------------------------
From: Giles Todd <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 14 Jul 1999 06:49:25 +0200
Reply-To: [EMAIL PROTECTED]
fungus <[EMAIL PROTECTED]> writes:
> ..."Dennis Ritchie", from "Bell Labs" ???
No. The other one.
Giles.
--
Saxo cere comminuit brum.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Differences in binary-based conversions.
Date: Wed, 14 Jul 1999 14:54:49 GMT
In article <NSUi3.141$[EMAIL PROTECTED]>,
"User" <[EMAIL PROTECTED]> wrote:
>
> Here is an interesting topic many people are confused
> about. In numeral "base" encryption, the conversion from ANY base
> to base 2 (binary) is not a simple mapping or expansion, it is
> numerically based. That means it is less susceptible to attacks from
> frequency analysis based on frequency of characters in the encrypted
text
> (ie,
> converted to another base).
Umm yes it is. You have to keep at least H(m) bits or you will not be
able to reverse the process. for example the alphabet requires about
4.6 bits per character. If you go less then this then you cannot
reverse the process. If you store a dictionary (i.e huffman tree) you
can reverse it but that's slightly different.
you cannot just simply convert to an arbitrary bit size and expect it
to reverse. And yes if you convert ASCII to binary it is still
vulnerable to frequency analysis. Freq analysis will work on anything
(no matter how big or how many bits), it is just infeasible against
larger blocks (say 64+ bits).
> Traditional conversion (ASCII)...
> A B C D E F (HEX or ascii )
> 65 66 67 68 69 (Decimal : )
> 1000001 1000010 1000011 1000100 1000101 1000110 (binary)
>
> Traditional conversion (non-ascii)
> A B C D E F (HEX)
> 11 12 13 14 15 16 (Decimal: no ascii )
> 01011 01100 01101 01110 01111 11111 (binary)
You are wrong though, 'F' in hex is 15 decimal not 16. These should be
4 bit numbers...
>
> Numeral base conversion.
> ABCDEF (HEX)
> 11259375 (Decimal)
> 101010111100110111101111 (binary)
You are not converting a message but a number, this is simlar to
encrypting a 64-bit numbe (block). If you had for example
'I shall see'
you would have 12*8 (96) bits of message. There is redundancies in the
the message (two spaces, 'e' and 'l') and it could possibly compress to
7.99*12 (95.88) bits. This is still vulnerable to freq analysis though.
> Notice the difference.. In numeral base conversion, compression is
already
> accounted for, while traditional conversion actually expands the
number
> of symbols many times. Note that in traditional conversion (as
opposed
> to base conversion), there is simple mapping between hex to binary on
> a symbol by symbol basis, and this can be attacked using frequency
> analysis. In numeral base conversion, however, there is a flattening
of
> frequency of symbols, and is less susceptible to frequency analysis.
>
How is decompression counted for? If you have to store a dictionary
then is it really encryption? You can't share a dictionary based on a
message you have not sent yet... And adaptive methods are not
private. So really how is this compression and how is it secure?
Just be converting a number to a different base does not omit
redundancy. Check this out
F O O F F A B E (hex)
15 0 0 15 15 10 11 14 (dec)
17 0 0 17 17 12 13 16 (oct)
And you should be able to find the base by examining the output and
seeing which chars appear more frequently. Plus how many bases are
there that are actually usable?
I don't see this as a 'strong' method...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: I wonder why he wrote it that way.
Date: Wed, 14 Jul 1999 15:49:46 GMT
"JOE" <[EMAIL PROTECTED]> wrote, in part:
>By the way, I don't recall reading that Rongorongo is related to Harappa
>glyphs.
There may be no actual relationship, but they *look* alike on a
superficial level. If you don't read the sort of books that discuss
the lost civilization of Atlantis, or the aliens from outer space that
taught humans the rudiments of civilzation, you may indeed have missed
claims of an actual relationship.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Differences in binary-based conversions.
Date: Wed, 14 Jul 1999 10:11:02 -0600
In article <NSUi3.141$[EMAIL PROTECTED]>, "User"
<[EMAIL PROTECTED]> wrote:
>... In numeral base conversion, however, there is a flattening of
> frequency of symbols, and is less susceptible to frequency analysis.
Any conversion between bases is apt to do distort frequencies. The big
question is how reversable you allow it to be. It seems that by adding
true crypto keyspace to the process is a good idea since the actual input
form of the message is not so easily available.
Consider that ASCII is the stupid norm for plaintext input. Therefore, if
all crypto is to work to that standard, all you need to do is to find
mechanisms that return you to it, simple conversions for example. It
seems better to find something else.
Relevant to the thread, SF had suggested that I investigate other bases
for character sets that can be changed to base 64. I have already posted
a cipher that went from Base 27 to Base 64. I'm looking a sixteen others
that end in Base 64.
Looking for naturally interfaced groups already used in other ciphers is
going to be hard since the list of lowest size of ciphertext groups in bit
form for 17 ciphers is 18, 18, 30, 30, 60, 66, 72, 102, 108, 114, 126,
132, 134, 138, 144, 150, and 210. Multiples of low numbers such as 36 are
easily added to the list. The input bases also in ascending order, not
necessarily paired with the above, are 22, 27, 31, 38, 41, 45, 46, 50, 53,
56, 62, 63, 76, 77, 80, 87 and 90. Intermediate information units for
transposition include six using bits(base 2), four using digits(base 10),
and the rest using doits(base 12). Odds are I made a mistake somewhere in
these quick calculations, but if implemented, any such trivial mistakes
get ironed out.
All are reasonable ciphers, even have names, although some have attrocious
blocksizes for text, as many as 35 characters for 210 bits. The small end
of the lists looks good if the plaintext sets are properly implemented in
text front-ends. My concept of implementations forever includes handling
the job from original text entry and back.
--
Most wrestlers and politicians seem to have pretty the same
agenda, seek various kinds of by appearing to do things they are
not doing, catering to specialty groups of supporters, and as a
result of deals, learn to take falls when they know better. Those
who do not go along tend to be excluded and punished.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Canadian Crypto
Date: Wed, 14 Jul 1999 15:53:15 GMT
"Daniel Urquhart" <[EMAIL PROTECTED]> wrote, in part:
>Basically crypto in Canada is still seems fairly open.
Deal: I won't attach binaries of a .PDF of the U.S. Consitution to my
posts...
Anyhow, on the front page of Monday's National Post (formerly the
Financial Post, Canada's answer to the Wall Street Journal, but now
changed to be a full-service newspaper) was an article indicating that
the U.S. and Canada are in negotiations to harmonize Canadian export
regulations with the U.S. ITAR, as a result of the possibility Canada
may lose many U.S. defence contracts due to two still-secret recent
incidents of technology diversion.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Funny News
Date: Wed, 14 Jul 1999 18:47:55 +0200
Doug Stell wrote:
>
> There is little doubt that encryption makes the job of the national
> security and law enforcement folks more difficult.
>
http://jya.com/ussc032699.htm
> The big criminals, such as organized crime, drug trafficing
> operations and well-funded terrorists, will tend to have very good
> security, because they recongnize its value and have the resources
> to obtain it. The little guys, such as the local kid selling drugs,
> no only finds it too expensive, but may be too stupid to use it.
>
Freeh always uses the "big guys" in his srguments. Local kids
aren't "terrorists" or "drug traffikers".
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Funny News
Date: Wed, 14 Jul 1999 18:51:40 +0200
James Andrews wrote:
>
> What kind of half arsed logic creates these laws?
"Judge the corruptness of a governemnt by the number of laws it
creates." - Tacitus.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Replacing IDEA with Blowfish
Date: Wed, 14 Jul 1999 15:47:08 GMT
[EMAIL PROTECTED] wrote:
> I am very skeptical about using Blowfish/Twofish in my applications.
I
> know that Bruce Schneier is very capable of creating a good encryption
> algorithm, but Blowfish has not withstood the attacks that IDEA has
(at
> least not yet anyway).
What are you talking about? Both algorithms are strong in
their uncrippled form.
Blowfish at least has nontrivial key scheduling. IDEA has
much weaker key scheduling, and much less internal state.
And IDEA uses math instead of S boxes. Using "math"
(e.g., mult. inverses mod 2^16+1) may lead to analytic
attacks based on the regularity of that construction. (Not that I'm
competent to perform them.)
Blowfish is more trustworthy, a priori, than Twofish simply
because Twofish is newer, although its being analyzed quite
extensively by its authors and others.
And IDEA is encumbered by licensing issues. IDEA only
got popular because PKZ picked it some years ago for PGP.
.......
As an implementor, not a cryptologist, what you care about
are 1. implementing the whole system securely 2. licensing
3. implementing the whole system securely.
Performance won't be an issue unless you're going really
fast or using a cheap platform. The security of the
cipher won't be an issue. Failing to take a system-wide
view of security (can you prove that your passphrase
is never swapped to disk? do you use enough physical entropy
when generating your random keys?) is the issue.
=========
"Terrorists are the only true avant-garde artists because they're the
only ones who are still capable of really surprising people."
---Laurie Anderson
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "donald tees" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Wed, 14 Jul 1999 12:03:28 -0400
John Varela wrote in message ...
>On Mon, 12 Jul 1999 22:15:52, [EMAIL PROTECTED] (Matthew Gates)
>wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> Boris Kazak <[EMAIL PROTECTED]> writes:
>> > Just as B(reast) has two N(ipples), B(yte) has two N(ibbles)
>>
>> Breast singular, two nipples?
>
>That's udderly ridiculous.
But an interesting titbit of info.
------------------------------
Date: Wed, 14 Jul 1999 10:23:55 -0600
From: Gabriel Belingueres <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
I don't understand why should I have to avoid using locals in my code.
I agree that after the variables containing round keys must be set to
zero. This is to avoid the last value remains in the stack.
If I don't use locals, I must use heap allocated vars. The heap bassed
variable must be "zeroed" anyway (and then deleted too).
In addition, writing directly an expression makes the compiler create a
local in the stack too, witch is worst because it can be zeroed
explisitly by the programmer.
So, having pointers for round keys, or writing expressions is not a
higher risk business than locals?
What happens if some pointer is lost?
Gabriel
[EMAIL PROTECTED] wrote:
>
> In article <7m2d7k$d02$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > This coding thing is good for for the security of the implementation
> or
> > is just a coding convention??
>
> Well for cleaness and optimizations. Most compilers can optimize lines
> of code if they are companded.
>
> i.e take part of RC4
>
> ---
> x = (x + 1) & 255
> y = y + state[x]
> ---
>
> Can be written as
>
> ---
> y += state[x = (x + 1) & 255]
> ---
>
> In fact RC4 can be written in about 3 or so lines of code. This makes
> the code faster on most machines and more compact on microcontrollers.
> It makes it harder to read as well.
>
> Take a look a my PRNG C++ file, you will notice that the stepping of
> the PRNGs look like
>
> ---
> return state[x = ni[++x]] += state[y = ni[++y]];
> ---
>
> Everything should be in the accumulator as required (i.e MCU
> friendly). Most compilers can optimize code like this better then if
> it were done in 3 or so lines...
>
> For security reasons you want to avoid putting round keys on stack (i.e
> auto/locals). This is not algorithm related but implementation
> related.
>
> Also naming locals the same as the globals (i.e procedure name and a
> argument) is a bad idea, some compilers will tolerate it (in fact they
> should) but who knows there might be a bug...
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Open source (e.g. GPL) banking project
Date: Wed, 14 Jul 1999 16:13:42 GMT
Dear Cryptographers,
I am interested whether you know of any open-source projects (e.g.
GPL, AL) in the realm of electronic commerce including strong
cryptography and especially whether there are any plans to set up an
open-source bank like the one proposed at http://www.nerdbank.org
(currently this is still vaporware).
If so, please tell me where, so that we can join forces. If not so, you
are invited to participate (and maybe to shift the regional bias away a
little from Germany/Austria).
Also, if you would suggest to reask this question in another forum, I'd
be grateful for that pointer.
Regards, Holger Blasum, Nerdbank project
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Derek Bell)
Subject: Re: CIA'KRYPTOS is cracked
Date: 13 Jul 1999 23:18:39 +0100
"collomb" <[EMAIL PROTECTED]> writes:
>Yesterday 5 july 1999�: GOD disposed diagonally
I can make out the words PIER and MATE two lines apart, running
left-to-right horizonally. Switching to Freudian terms, I can find EGO spelled
out horizontally, and ID spelled out vertically to the left of that. All
*without* resorting to diagonals, which would increase the number of possible
words that could be spelled out.
If the text is large enough, you can make out nearly any words you
like.
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Electronically Exporting crypto source (legally)
Date: Fri, 09 Jul 1999 06:42:24 GMT
Dmitri Alperovitch wrote:
> Any ideas/comments about this?
Yes -- the prosecution and the courts will judge your *intent*.
------------------------------
From: [EMAIL PROTECTED]
Subject: Why public key in PGP
Date: Wed, 14 Jul 1999 16:40:36 GMT
Question:
Now that you publish your public key for a PGP encrypted file, why
do you need such a public key?
Do you really need a key server to dynamically generate new
public keys? How if you just use one public key for a long time (say, 1
month or 10 years)?
Thank you so much.
Weedlet
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: wincrypt.h
Date: Wed, 14 Jul 1999 17:20:15 GMT
i am trying to do a simple encryption using
wincrypt.h from vc++. but when i use the
functions and types defined in the wincrypt i get
undeclared identifier errors.if i include
_win32_winnt 0x0400, i dont get the undeclared
identifier errors in the code, but syntax errors
in the wincrypt.h header file. what should i do?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Philip Kappaz <[EMAIL PROTECTED]>
Subject: Music on CD - Great for around the house or dinner
Date: Wed, 14 Jul 1999 11:47:29 -0500
Greetings,
Please take a few moments to check out my music. I have created a CD
(only $5.99) of excellent quality recordings of some very nice,
enjoyable music. My music is a mixture of the smooth jazz, latin, and
new age styles, and it is all designed for the pleasure of my listeners.
Check out "Awakening", a short, romantic, symphonic work. Both "The
Lost World", and "Dream Catcher" have a nice quiet latin rhythmic bass
for some beautiful orchestrations with my keyboards. Please take a
listen, and hopefully you will even purchase your own copy. You will
not be dissapointed.
Thank you,
Philip Kappaz
http://www.mp3.com/kappaz
------------------------------
Date: Wed, 14 Jul 1999 10:11:48 -0600
From: Gabriel Belingueres <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
I agree with Jerry about the optimizations.
If you are going to usa Micro-C, then it is fully justified to do as
much optimizations as you can, but if you are going to use MS C/C++ or
Borland C++ (common cases), you can optimize your code using tools like
Intel's VTune or something like that.
I believe that easy of reading is a must.
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Jerry Coffin) wrote:
> > In article <7m2eeh$di7$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > says...
> >
> > [ ... ]
> >
> > [ rewriting ]
> >
> > > x = (x + 1) & 255
> > > y = y + state[x]
> >
> > [ as ]
> >
> > > y += state[x = (x + 1) & 255]
> >
> > [ ... ]
> >
> > It's open to argument whether it's harder to read, but there's little
> > room for argument that with the vast majority of compilers, rewrites
> > like this will make absolutely NO difference whatsoever in the object
> > code. I'd almost go so far as to say that any compiler that produced
> > different object code for these two pieces of code wasn't working
> > correctly, but that might be over-stating things a bit.
> >
> > In any case, a rewrite like this is rarely likely to have any effect
> > at all on the size of speed of the object code.
>
> That's not true. Micro-C (low cost embeded C compiler,
> www.dunfield.com) will prefer the later because it will keep the value
> in the accumulator. It has a optimizer which will optimize the first,
> but why?
>
> Most codegens do a good job with the latter, it helps avoid unneeed
> load/store operations plus makes good use of the registers.
>
> I prefer the later just because I don't know which compiler will be
> used and I would rather have good code on all platforms.
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
--
Gabriel Belingueres
------------------------------
From: [EMAIL PROTECTED] (Natarajan Krishnaswami)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 14 Jul 1999 17:10:36 GMT
Reply-To: [EMAIL PROTECTED]
On 14 Jul 1999 13:52:53 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hey, we used our toes, too!
Well, you could count in binary. You can count up to 1023 on two
hands.
<N/>
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Canadian Crypto
Date: Wed, 14 Jul 1999 16:38:53 GMT
>Anyhow, on the front page of Monday's National Post (formerly the
>Financial Post, Canada's answer to the Wall Street Journal, but now
>changed to be a full-service newspaper) was an article indicating that
>the U.S. and Canada are in negotiations to harmonize Canadian export
>regulations with the U.S. ITAR, as a result of the possibility Canada
>may lose many U.S. defence contracts due to two still-secret recent
>incidents of technology diversion.
Keep us posted, John.
In my past discussion with both countries, both claim to currently
have the same regulations. However, they seem to be applied very
differently. So, harmony must include not only the regulations, but
their interpretation and application.
For example, a Canadian firm can sell an encryption DLL that can be
linked into many applications. In the US, the agency insists on
tightly coupled crypto and forbids the use of DLL. ("Crypto with a
hole" is the term.) I was with a US firm who was looking at being a
reseller of the Canadian firm's capability and we couldn't do it. The
US is clearly at a disadvantage in the marketplace.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Problems with the RC4 algorithm
Date: Wed, 14 Jul 1999 16:52:09 GMT
On Tue, 13 Jul 1999 20:35:36 -0400, [EMAIL PROTECTED] wrote:
>I seem to be having trouble implementing the RC4 algorithm. As far as I
>can tell, the algorithm seems very simple and easy to understand, but
>when I try to encrypt and then decrypt a message using it, it never
>seems to work. (Just garbled text.) I am wondering if I am using it
>wrong. Here is the code I use:
Tom identified the problem correctly.
RC4 is a stream cipher. It outputs a byte stream that is unrelated to
the data and you XOR that byte stream with the data. Therefore, RC4
cares about and only about the number of bytes that have been
generated since the last initialization of the state.
By not reinitializing the state, you have essentially done two passes
of encryption over the data, rather than an encyrption and decryption.
(Encryption and decryption are identical operations with the identical
byte stream.)
------------------------------
** 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
******************************
