Re: Another Dumb Idea for Debunking...


Ben Rudiak-Gould wrote:
Bill Cox wrote:
I've gone ahead and written a new encryption program. I can't help it
- it was FUN. It's at tinycrypt.sourceforge.net.

I have no objection to this except for the last sentence. You seem to
understand that there's little chance that your code is secure; under the
circumstances it seems irresponsible to release it on sourceforge.

Looking at your algorithm, the most obvious problem I can see is that
randVal will always be even at the end of each loop, meaning that the least
significant bits of the output are only slightly obscured. I'm sure that
someone else here could come up with a complete break if they took the time,
but you might find it a good exercise to try this yourself.

The famous cipher RC4 is about as simple as your algorithm and probably
about equally fast. It has known flaws, but they can be worked around if
you're careful. AES is pretty darn fast too.

-- Ben

Thanks for the feedback. I'm impressed you found that randValue is
always even. Knuth warned that the low bits were not very random.
I've posted a stronger warning on the tinycrypt.sf.net site warning of
it's insecurity, right on the top in bold. I just read about RC4 on
Wikipedia.org. I must admit, it's at least as fast, probably faster.
I'm thinking of swaping out the SimpleCrypt encryption with a slight
variation on RC4.

You said RC4 could be used securely if you are careful. Can you
elaborate, since I'm going to try to use it in TinyCrypt?

I'll explain why I hope TinyCrypt may have value, and thus the sf.net
post. I wrote TinyCrypt after reading the following statements:

"Cryptanalysis relies on exploiting redundancies in the plaintext;
compressing a file before encryption reduces these redundancies.
Encryption is time-consuming; compressing a file before encryption
speeds up the entire process." - page 226 in "Applied
Cryptography."

"On modern systems, when making backups of terrabyte of data, lzop is
usually IO-bound and not CPU-bound, which means that you can both
decrease storage requirements and effectively reduce backup time by
quite an amount." - www.lzop.org

So, I can code a fast, secure encryption algorithm that is faster than
LZO compression, I could provide three wins: less disks space, faster
disk access, and improved security. I looked a bit for such a project
for Linux, but couldn't find one.

This is the original RC4 SNRG (from Widipedia.org). The S array is a
key-scrambled permutation.

i := 0
j := 0
while GeneratingOutput:
i := (i + 1) mod 256
j := (j + S[i]) mod 256
swap(S[i],S[j])
output S[(S[i] + S[j]) mod 256]

This output is then XOR-ed with the file to encrypt it. If you use the
same key on two files, all you have to do is XOR the two encrypted
files to get the SRNG output, which can then be XOR-ed with both files
to decrypt them. The version used in WEP appended a random number to
the user's key, thus changing the SRNG output, but that wasn't enough
to foil attacks that had lots of encrypted samples.

I like adding the entropy from the user's file back into the entropy of
the key, as you may have noticed in SimpleCrypt. It's basically cypher
block chaining. This might help foil the attack against RC4:

i := 0
j := 0
for each character in input file 'c':
i := (i + 1) mod 256
j := (j + S[i]) mod 256
swap(S[i],S[j])
output := S[(S[i] + S[j]) mod 256]
j := (j + plainTextChar ) mod 256

The plainTextChar is the input char if encrypting, and the output char
if decrypting.

Regardless of the lower-level encryption, TinyCrypt hopefully adds
security by randomizing the input data by a first encryption with a
random key, and then encrypting with the user's actual key. Is this
good enough, or are there other steps I should take?

Thanks,
Bill

.

Relevant Pages

  • 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: 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)
  • Re: RC4 broken?
    ... >same secret key, and the method fails if two iterations of RC4 are used. ... Few encryption algorithms have had the intense ...
    (sci.crypt)
  • Re: Another Dumb Idea for Debunking...
    ... I've switch TinyCrypt to using it. ... The first encryption is with a random ... random key, and then encrypting with the user's actual key. ...
    (sci.crypt)