Re: Questions about arc4 - post updated

From: Giorgio (giorgio_at_bignami.zzn.com)
Date: 05/20/04 

Date: 19 May 2004 23:59:24 -0700

Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message news:<c8gnga$2qb$02$1@news.t-online.com>...
> Giorgio wrote:
> [snip]
> > This question still remain, what about a "3-arc4"?
> I doubt that I properly understand what you meant. Anyway,
> would that be essentially different from, say, xor-ing
> three RC4 streams?
No, it would not be different, is just what i was thinking.
Since space for RC4 state arays is about 256! I think that would be
very improbable that for n RC4 streams (generated with different keys)
would exist n-x streams with the same output on a given byte, so a
triple encryption with indipendent RC4 streams would not probably
collide with an encryption that is possible to obtain with two or one
stream, so to decypher all tree keys should be known since it's very
improbable that a number of keys lessen than tree would decypher the
cryptogram brute forcing it with RC4.
I know this is not equivalent to say that a triple- (or n-) RC4 would
be strong as an hypothetical RC4 with key of triple (or *n) length,
but odds are that it is meaningfully strongher than single RC4. Is RC4
algorithm suitable to be used in this way?
How much strongher it will be? Does exists studies about it?
And how does it would impact on the flaw of slightly unbalanced output
of rc4 that make it somewhat vulnerable if used to encrypt more than
1/1,5 GB with the same key?
The n-RC4 encryption could be done in a single pass but I was also
thinking doing it in different passes, hashing the encrypted message
after each pass except the last, then with decryption receiver can
control if the hash is correct; if the hash is not correct, possibly
message was altered or corrupted. This, IMHO, would add to RC4 a
basical resistance to substitution of bytes that would be otherwise
not detectable.

Relevant Pages

  • Re: How to decrypt RC4 w/ managed code?
    ... We're migrating a COM application that uses the Crypto API to ... RC4 is not supported in the .NET Framework. ... (which is how the keys were derived in the encryption phase). ... As part of your migration, have you considered decrypting the data and re-encrypting it using a supported, safer, encryption scheme? ...
    (microsoft.public.dotnet.security)
  • Re: Native RC4 code
    ... i'd rather advise you to avoid using RC4 encryption, ... drop them before using RC4 stream, you can never reuse key stream +++. ... I'm new in encryption and I have a question. ... I have a public key, a .p7b file, how can I load the public key and use ...
    (microsoft.public.dotnet.security)
  • Re: Questions about arc4
    ... > Making a more secure version of RC4? ... Why not use AES? ... 256 bytes keys, that is something bigger than RC4-8bit ones (keys ... The problems in state array setup how behave in the 16 bit mode? ...
    (sci.crypt)
  • Re: RC4 broken?
    ... Few encryption algorithms have had the ... >> time that the first few bytes output by RC4 were ... >> the secret key the secret key ...
    (sci.crypt)
  • Re: how these 2 functions may differ?
    ... you not using the encryption functions built in to Windows? ... as far as I know there isn't any .net builtin RC4 ... Windows has RC4 builtin. ... it should have been as simple as calling new CryptoAPITransform ...
    (microsoft.public.dotnet.languages.csharp)