Results 1 to 7 of 7

Thread: interleaving 2x 256bit = 512bit encryption ?

  1. #1
    Member
    Join Date
    Sep 2007
    Location
    Denmark
    Posts
    856
    Thanks
    45
    Thanked 104 Times in 82 Posts

    interleaving 2x 256bit = 512bit encryption ?

    i was just theoretically wondering if you could call this a 512bit encryption ?

    you "split" the file into 2 channels of 128bit block and interleave them into a 2 encrypters with different encryption keys.

    so that AES take 1st,3rd,5th ... block
    and serpents takes 2nd,4th,6th.... block


    both the encryption keys will be derived from the same password but with different hashing methods and different salt.
    Last edited by SvenBent; 30th August 2009 at 02:53.

  2. #2
    Member biject.bwts's Avatar
    Join Date
    Jun 2008
    Location
    texas
    Posts
    449
    Thanks
    23
    Thanked 14 Times in 10 Posts
    Quote Originally Posted by SvenBent View Post
    i was just theoretically wondering if you could call this a 512bit encryption ?

    you "split" the file into 2 channels of 128bit block and interleave them into a 2 encrypters with different encryption keys.

    so that AES take 1st,3rd,5th ... block
    and serpents takes 2nd,4th,6th.... block
    I would call it 129 bit encryption. Generally its hoped for every single bit of key space used when you go say from 4 bits to 5 bits. it twice as hard to break as the 4 bit key. You have two 128 bit encryptions on alternating blocks you have two separate 128 bit problems. doubling the work. Which is like have one extra bit. That's my take on it. But I am not knowledgeable in this field or the NSA would have hired me years ago.
    That is when they still wanted people with talent.

  3. #3
    Member biject.bwts's Avatar
    Join Date
    Jun 2008
    Location
    texas
    Posts
    449
    Thanks
    23
    Thanked 14 Times in 10 Posts
    Quote Originally Posted by biject.bwts View Post
    I would call it 129 bit encryption. Generally its hoped for every single bit of key space used when you go say from 4 bits to 5 bits. it twice as hard to break as the 4 bit key. You have two 128 bit encryptions on alternating blocks you have two separate 128 bit problems. doubling the work. Which is like have one extra bit. That's my take on it. But I am not knowledgeable in this field or the NSA would have hired me years ago.
    That is when they still wanted people with talent.
    sorry missed what you worte thought it was 128 bit see its 256 bit
    so its like a 257 bit system. I am getting to old for this.

  4. #4
    Member
    Join Date
    Sep 2007
    Location
    Denmark
    Posts
    856
    Thanks
    45
    Thanked 104 Times in 82 Posts
    just to clear something up the channels are 128it because both serpent and AES works on 128bit block. but the encryption keys will be 2x256bits


    anyway

    you would still be needing 2^256* 2^256 combinations to brute alle keys that the same as 2^512

    if you go through 129^2 keys you woulde only have broken the first key and one bit of the second key. The 127 keys left has not been flipped at all

    ...
    now it comes to me that what you are saying that it is possible to gor thought one key at at time.
    thereby doing 2^256+2^256 whichas are indeed are 257 bits of combination

    would it be better to split the channels by 1 bytes/bit and preencrypt the data with simpleXOR previous bytes/bit.
    thereby when only key on is broken the rest of the files is still not readable because you need clear data behind the second key to xor the data behind the broken key

  5. #5
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,134
    Thanks
    179
    Thanked 921 Times in 469 Posts
    The encryption complexity is determined by the size of key space,
    and with encryption of compressed data a plaintext attack on
    any block other than first is not really possible anyway.
    Also, for 128 bits of key space you'd need like a 64-byte text
    passphrase... or a 22-byte random base64 string.
    Which is very unlikely, so the actual keyspace would be much smaller.

    Anyway, afaik, the real 128-bit encryption is done differently.
    The actual key is randomly generated and encrypted with another
    algorithm, like RSA.
    Which can be made really hard to crack, as there's only a small
    chunk of data to encrypt.

  6. #6
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 778 Times in 485 Posts
    128 bit encryption really means that it takes 2^128 work to break it using a chosen plaintext attack. So if you interleave two ciphers it is really only 129 bits of security.

    Compression does not add to security significantly. The compression algorithm is not secret. In any case, you can't assume a ciphertext-only attack.

    Maybe encrypting data twice with 2 independent 128 bit keys could be considered 256 bits. But there is no guarantee you aren't introducing other weaknesses this way. You are assuming that there is no way to tell if you found one of the two keys. Suppose you derive your two keys from a 160 bit hash like SHA-1. Then you have 160 bits of security, not 256. Actually less because there are some theoretical attacks on SHA-1 even though no collisions have been found.

    In fact there are no provably secure systems other than one time pad. The only way you know that a system is secure is if lots of people try to break it and fail. But we continue to be surprised.

  7. #7
    Member
    Join Date
    Sep 2007
    Location
    Denmark
    Posts
    856
    Thanks
    45
    Thanked 104 Times in 82 Posts
    Please note tthat I'm only using logic as i have almost non programming or encryption skills (did some xor encryption many years ago)

    but dlb encryption with 2 keys would be way worse then my suggested according to my logic
    for the simple reasong that the buildt-in check to see if file is decrypted correctly occurs after the first 256bits and then after the next 256 bits

    making it EXACTLY 256bits + 256 of combinations = 257bits of combination

    my suggestion where you need to decode with both keys before you can cetify the data the with the buildt-in routine for checking correctly decoded data is behind 512bits


    i don't know how decryption check to ensure the data is correct but let me show it with a simple md5 chekcsum of the file

    2x encryption you brake with brute forcing like this

    decrypt with key (256bits)
    check md5
    if corret go on
    decrypt with key (256bits)
    check md5

    that would be exactly 257bits of combination

    however wit my interleaving you would need to brake both keys before the md5 of the file would check (not taking collisions into account as its not really important here)

    off cause plain text attacks is another story but the buildt-in check is more secure by interleaving the encryption key rather then applying on top of each other.
    UNLESS you move the check of the first key behind the second key
    Last edited by SvenBent; 30th August 2009 at 21:26.

Similar Threads

  1. Idea: Combine Compression & Encryption
    By dirks in forum Data Compression
    Replies: 16
    Last Post: 22nd February 2010, 11:49
  2. XOR encryption
    By encode in forum Data Compression
    Replies: 12
    Last Post: 16th March 2009, 10:49
  3. Swap Encryption
    By encode in forum Data Compression
    Replies: 4
    Last Post: 28th October 2008, 16:55
  4. Simple encryption (RC4 like)
    By encode in forum Forum Archive
    Replies: 37
    Last Post: 26th January 2008, 04:05

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •