Results 1 to 10 of 10

Thread: VB6 - Unnamed Encryption Routine

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,470

    VB6 - Unnamed Encryption Routine

    Working with CNG (Cryptography Next Generation) can sometimes be a little frustrating, and often times MS is slow to add support for newer algorithms. So I came up with my own streaming Encryption routine that operates in VB6. Comments are welcome.

    CNG is used to create the random key used for testing. The bytes within this random key are then shuffled using information obtained from the key itself. The shuffled bytes are then hashed to prevent matching of the shuffled bytes to the original key, and this is then XOR'd in a rotating fashion with the Plain Text to produce the Encrypted Text. The final key used in the XOR operation is never held in memory, thereby preventing a hacker from recovering it from memory.

    J.A. Coutts

    Updated: 04/12/2016
    Attached Images Attached Images  
    Attached Files Attached Files
    Last edited by couttsj; Apr 12th, 2016 at 06:10 PM.

  2. #2
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB6 - Unnamed Encryption Routine

    Quote Originally Posted by couttsj View Post
    So I came up with my own streaming Encryption routine that operates in VB6. Comments are welcome.
    I can only recommend, that nobody should use the above stream-cypher,
    because it's highly insecure.

    It is vulnerable with the "known content"-attack...

    Meaning, when an attacker knows the first bytes in the encrypted stream -
    (as might be the case when you for example encrypt http-requests,
    or you send encrypted files with "known header-fields") - then one
    can easily derive your cycling XOR-Key from the encrypted content.

    Also, if the encrypted content is large enough (e.g. a larger Text-Document
    with - say - more than 30KBytes of Text, then the XOR-Key is equally
    easy reconstructable with probability-matching of certain text-chars.

    Olaf

  3. #3

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,470

    Re: VB6 - Unnamed Encryption Routine

    Olaf;
    To be honest, I did not consider the situations you have outlined, but I can see how it would not be difficult to figure out the XOR value in those situations.

    I tried to follow the ChaCha algorithm in RFC 7539, but I have to admit that I do not completely understand it. Modulus arithmetic is not easy to implement IN VB, and I am open to suggestions on how to improve upon this unnamed algorithm.

    Thank you for your feedback.

    J.A. Coutts

  4. #4
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB6 - Unnamed Encryption Routine

    Quote Originally Posted by couttsj View Post
    I tried to follow the ChaCha algorithm in RFC 7539, but I have to admit that I do not completely understand it. Modulus arithmetic is not easy to implement IN VB, and I am open to suggestions on how to improve upon this unnamed algorithm.
    The way almost all of the stream-cyphers work, is that they not just "repeatedly apply"
    their Keys directly (in a circular fashion). The Keys in such algos are used, to "seed"
    (and re-seed) a Random-Number-XOR-Byte-Generator, which should have a very high
    Period, before any XOR-patterns are repeated...

    In case of the RC4, this random "Key-Shuffeling" has a period of about 2^1500.
    From what I've read on Wikipedia, the ChaCha-KeyStream-PRNG is better, but still
    based on that of the RC4-algo.

    To re-implement e.g. ChaCha on your own, you will have to really take care, that you
    will not make any mistakes whilst porting from C- or Java (or from pseudo-code) -
    followed by tests with known keys and known content, to verify that you will produce
    the same encrypted stream-output.

    Inventing your own Algo is mostly not a good idea, when you're not working for
    a few years in that field (having a math- and crypto-background).

    Good Crypto-Algos are open - and well-analyzed by crypto-experts and mathematicians
    the world over - all we can do here from our end is, to come up with at least correct implementations.

    Olaf

  5. #5

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,470

    Re: VB6 - Unnamed Encryption Routine

    I hear you. I have often joked that cryptographers spend half their life coming up with a good algorithm, and the other half trying to pick holes in it.

    So if I read things correctly, if a hacker knows the underlying plain text, there is no way to prevent the hacker from figuring out the first XOR block used. One just has to be careful not to repeat that block. In the case of ChaCha, that repeatable length is 256 GB. What if we randomly pre-padded the plain text and then discarded it on decryption? That should make the first block less susceptible. But then the padded length would not be the same as original length. Or we could use an Initialization Vector to separate the first block from the subsequently derived blocks. I think i am getting a headache.

    J.A. Coutts

  6. #6
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB6 - Unnamed Encryption Routine

    Quote Originally Posted by couttsj View Post
    So if I read things correctly, if a hacker knows the underlying plain text, there is no way to prevent the hacker from figuring out the first XOR block used.
    Not only the first block (I meant that "first block thing" more in a way, that it is mostly within
    the first bytes of a sent message (or file), where "known-header-fields" are placed.

    So the problem with your current algo is not just with the "first XOR-Block" - the problem is,
    that you *repeatedly use* that same first XOR-Key-Block also against subsequent MessageBytes
    (your Keystream is quite short - and repetitive, which is a "no go").

    Quote Originally Posted by couttsj View Post
    What if we randomly pre-padded the plain text and then discarded it on decryption?
    This wouldn't help, since your problem is not with "letting your KeyStream-PRNG swing-in
    and warm-up for a bit" - it is that you have no KeyStream-PRNG at all in your algo.

    Just encrypt a simple message which is e.g. 128 Bytes long - and contains only Zero-bytes.
    In that case your XOR-KeyStream is entirely "open in the clear" (directly readable) -
    and (as said) it repeats itself (any "Key-Hash-Length"-Bytes - in your case 32Bytes),
    below is your original program-output for such a 128-ZeroBytes-Message (the XOR-Key repeating itself 4 times):
    Code:
    39 EB 45 DD 50 FC 58 17 BC 95 CE 94 CC 4B 18 87 
    54 C1 60 45 A0 F2 BF 50 D4 2A 8F 3A EC 19 EB 5D 
    39 EB 45 DD 50 FC 58 17 BC 95 CE 94 CC 4B 18 87 
    54 C1 60 45 A0 F2 BF 50 D4 2A 8F 3A EC 19 EB 5D 
    39 EB 45 DD 50 FC 58 17 BC 95 CE 94 CC 4B 18 87 
    54 C1 60 45 A0 F2 BF 50 D4 2A 8F 3A EC 19 EB 5D 
    39 EB 45 DD 50 FC 58 17 BC 95 CE 94 CC 4B 18 87 
    54 C1 60 45 A0 F2 BF 50 D4 2A 8F 3A EC 19 EB 5D
    So, in case you send e.g. a TrueColor-Bitmap-File, which contains a Black-Horizontal line
    of just some 15-60 Pixels length somwhere (which is common) - your Key would be entirely
    in the clear for such "black- or otherwise zeroed" content - no matter how long a pre-padding
    you will have used on your data.

    Such constantly repeating blocks in your encrypted messagestream are easily detectable by an attacker.

    Olaf

  7. #7

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,470

    Re: VB6 - Unnamed Encryption Routine

    I guess what I inferred but did not specifically state was that the key stream was made non-repeatable. My concern is with the first block of the key stream. In the example below, I encrypted 128 bytes of &HFF. Knowing the input text stream, it is very easy to figure out the first XOR block. Since the algorithm is open to public scrutiny and analysis, it is then possible with enough computing power to figure out the original key. It is made a little more difficult in this case because the original key is not only hashed, but randomly shuffled before hashing. Once you have the original key, the complete message is easily decrypted.
    Code:
    Plain Text
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
    
    Encrypted Text
    66 B1 CB ED 92 53 EA 3D 72 1F 97 CE 48 1F 04 C5 
    49 71 C2 C0 90 54 74 A5 69 21 F6 38 E0 C4 55 C5 
    A1 42 EA 8D 2F 96 F3 39 DB 29 DA 11 86 E3 54 34 
    7A F2 CC AE 66 79 45 9D B4 99 07 C7 8D 9C A3 E7 
    9B 68 75 90 3F 59 A6 C9 B1 D9 48 01 FC AE 78 AA 
    CF BF B3 01 81 72 92 AE 71 C1 8B 89 71 5F C3 9E 
    BB 80 85 AC 25 9B 3D 8D 94 27 4A D6 CC 75 40 D5 
    9A F8 9D 90 1A 32 D0 31 CF AF 9E 26 86 72 FB CC 
    
    First XOR block
    99 4E 34 12 6D AC 15 C2 8D E0 68 31 B7 E0 FB 3A 
    B6 8E 3D 3F 6F AB 8B 5A 96 DE 09 C7 1F 3B AA 3A 
    
    Random Key
    5B A5 61 39 96 2A FB 86 75 89 65 35 D6 08 27 BA 
    F6 06 EF 38 38 DC 86 F9 01 DD AA 09 D3 09 43 48
    This is a lot of work for a single random key, but not for a reusable key. It seems to me that the first block needs more protection.

    J.A. Coutts

  8. #8
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB6 - Unnamed Encryption Routine

    Quote Originally Posted by couttsj View Post
    I guess what I inferred but did not specifically state was that the key stream was made non-repeatable...
    Currently (in the Zip you have included in your original post) this is not the case -
    it will only make sense to analyze potential weaknesses further, when you'd
    upload the new sources (as the new base for discussion).

    Olaf

  9. #9

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,470

    Re: VB6 - Unnamed Encryption Routine

    Quote Originally Posted by Schmidt View Post
    Currently (in the Zip you have included in your original post) this is not the case -
    it will only make sense to analyze potential weaknesses further, when you'd
    upload the new sources (as the new base for discussion).

    Olaf
    As a quick fix to make the key stream non-repeatable, I added a single line to the Encrypt function;
    Code:
            Else
                lPtr2 = 0
    ****************************
                jfghlg = HashData("SHA256", jfghlg)
    ****************************
            End If
    It was not intended to be a permanent fix, so I did not update the zip file. Your feedback has helped me realize that repeatability is an issue that must be addressed, and in the process I am now realizing that the first XOR block is also a potential issue that could benifit from further examination. Hence my last posting. Neither of the fixes that I have come up with (padding/IV) are that attractive.

    J.A. Coutts

  10. #10

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,470

    Re: VB6 - Unnamed Encryption Routine

    The solution turned out to be quite simple. I started the first loop using the random number generated from the original key. This shortens the length of the first XOR block, adding a further degree of difficulty to any attempt to back calculate the original key using the first XOR block.

    J.A. Coutts

Posting Permissions

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



Click Here to Expand Forum to Full Width