symmetric encryption

[mindevolution]

ok i've looked at a lot of the symmetric encryption algorithms, however, they usually only have up to 256bit keys eg AES.

so i have this code that allows any length file to be used for a text key (cryptkey). does this make the following algorithm stronger?

Private Sub Crypt(Path As String, CryptKey As String, CryptNumber As Double)
    ' 1. loads file to be encrypted in Path, into a bite array
    ' 2. loads in any length file contained in CryptKey into a bite array and xors it 
'against the stream of bits of file to be encrypted

    If Len(Dir$(Path)) Then
        Dim ba() As Byte, nba() As Byte, kba() As Byte, i&, n&, ff&
        n = FileLen(Path)
        ReDim ba(n - 1): ReDim nba(n - 1) ' Resize byte arrays to hold all bytes in file
        ff = FreeFile
        Open Path For Binary Access Read As #ff
        Get #ff, , ba() ' read file into byte array
        Close #ff
        Kill Path ' kill existing file now have file in ba()
        
        n = Len(CryptKey) ' get length of CryptKey
        kba = StrConv(CryptKey, vbFromUnicode) ' convert CryptKey into byte array
        Rnd -1 ' calling rnd with a negative number before randomize allows rnd sequence to be reproduced
        Randomize CryptNumber
        For i = 0 To UBound(ba)
        nba(i) = ba(i) Xor kba(i Mod n) Xor Int(Rnd * 256) 'Xor each byte with a random number as well as CryptKey
        Next i
        
        ff = FreeFile
        Open Path For Binary Access Write As #ff
        Put #ff, , nba() ' Write encypted bytes back to file
        Close #ff
    End If
End Sub

[mindevolution]

with such small key sizes for the authorised algorithms, do they want people to be insecure? 256 bits is tiny!

with the algorithm I posted and using a very large text file as the key, it has to be a million times more secure than the "authorised" symmetric encryption algorithms.

or am i missing something?

[koutote]

I am afraid NO!

Your encryption is quite simple and I would say quite dangerous
to be decrypted easily. Do not underestimate the current well known
encryption algorithms, such as AES etc, they might have only 128 or
256 bits long cipher keys however their strenght is not coming from
the length only. Have many other properties such as many iterations,
shifts, replacements in Galois mathematics and others which make them stronger and immune in attacks and even in brute force cases.

And a software programming note, by killing a file this does not mean
that is being deleted from your hard disk drive!

[mindevolution]

thanks for the reply, however, with a 128/256 bit key, i think such encryption is not strong and I am wary of it. for example the Rijndael algorithm can be changed to accept a key of any length key:

http://www.iaik.tugraz.at/research/k...jmen/rijndael/

"Both block length and key length can be extended very easily to multiples of 32 bits"

however, the majority of the implementations are restricted to 128/256 bits which means they have crippled the strength of their encryption on purpose. I do not trust such crippled protection . it seems like most people think they are securely protected, when they are not, and could be much much better protected.

xor encryption is strong encryption depending on key size, and many of them include it if not all, if you look at their algorithms eg http://en.wikipedia.org/wiki/Interna...tion_Algorithm

sure they shift a block here and shift a column there, however, at the end of the day it is the key size that matters the most in terms in terms of offering extra protection. squeezing more "protection" from 256 bytes seems like a waste of time to me.

i have unlimited key size in my app and regularly use 30 page documents as keys for my encryption and encrypt entire sections of my harddrive quite quickly. if you think about it you only have to load in the large key file into memory once and apply it to all the files on your harddrive, which means it is possible to have absoultely huge key files and fast encryption like my app.

it may not be overly complicated, but xor with large keys is highly effective, and i would trust it over a tiny little 256 byte key.

can someone explain why they insist on such small keys?

i am working on the kill problem at the moment

[mindevolution]

i realised the rnd function is only 32 bits and can be decompiled from the application, and so it doesn't offer any proper protection. so it is now out of the algorithm.

next thing I noticed was that when the length of any file is less than the length of the key, the algorithm doesn't apply the whole key to the file. So in effect there is less protection for small files. I think I will need to fix this part of the algorithm.

any other weaknesses?

[koutote]

Ok, this is quite interesting topic....

My comments below:

1. Your link in wikipedia refers to IDEA which applies XOR but this
is the case for Rijndael too

2. Yes, your encryption method is faster than AES but also more
simple....As you already state, what happens if your original file
that you want to encrypt is only 90 bytes long (a simple text?)

3. I think that an expert on attacks with tools like brute force and a good dictionary on your language you encypt (or even with library of words, sentences etc ) will decrypt your files easily. Try any byte, then next one
next etc....until he finds the correct byte that make a sence word....
You should add I think some convolution in time (as in IDEA i think) at least
to eliminate this....

4. The Rijndael has 128 bits key lenght, but at the same time this key is expanded for each iteration, for 10 iterations you have 1280 bits long
However authors claim that keys between iterations are independent but
this is another question.....

[mindevolution]

it is possible to make xor harder to decode than a one time pad

and without any randomness to the keys

[mindevolution]

it is possible to make xor harder to decode than a one time pad

and without any randomness to the keys

ah yes, the key may not be random, but then you would have to apply some degree of randomness to the process wouldn't you?

[mindevolution]

ah yes, the key may not be random, but then you would have to apply some degree of randomness to the process wouldn't you?

yes that's true

[mindevolution]

yes that's true

you know you really must think of someway to deal with a plaintext attack don't you think?

[mindevolution]

you know you really must think of someway to deal with a plaintext attack don't you think?

ok, i think about it and get back to you

[mindevolution]

also reusing a key doesn't make it weaker, because finding a pattern doesn't help find the key.

[mindevolution]

so, sunburnt:

Assuming
1) Your key is the same length as the data to encrypt
2) Your key is completely random
3) Your key is never reused

i don't agree, the security only has to do with the length of the key and not with any of 1,2, or 3.

[cleverconcepts]

easily stated:

Xor performance > any other published encryption algorithm.

[dunno]

The One Time Pad is very efficient but requires 1 random bit for every plaintext bit. Being random bits hard to obtain in practice, the one-time pad is quickly dismissed and symmetric encryption schemes with short (and fixed-length) keys (aka block ciphers) are preferred.
Still, one popular mode of operation to encrypt long messages using block ciphers is essentially a one-time pad between plaintext and pseudo-random data that came out of a repeated application of the block cipher.

[cleverconcepts]

can you do a quick calculation of the probability of a plain text attack?