-
Apr 8th, 2016, 12:31 AM
#1
-
Apr 8th, 2016, 02:10 PM
#2
Re: VB6 - Unnamed Encryption Routine
Originally Posted by couttsj
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
-
Apr 8th, 2016, 10:43 PM
#3
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
-
Apr 9th, 2016, 05:40 AM
#4
Re: VB6 - Unnamed Encryption Routine
Originally Posted by couttsj
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
-
Apr 9th, 2016, 01:07 PM
#5
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
-
Apr 9th, 2016, 05:57 PM
#6
Re: VB6 - Unnamed Encryption Routine
Originally Posted by couttsj
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").
Originally Posted by couttsj
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
-
Apr 10th, 2016, 11:19 AM
#7
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
-
Apr 10th, 2016, 12:21 PM
#8
Re: VB6 - Unnamed Encryption Routine
Originally Posted by couttsj
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
-
Apr 10th, 2016, 10:54 PM
#9
Re: VB6 - Unnamed Encryption Routine
Originally Posted by Schmidt
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
-
Apr 11th, 2016, 08:46 AM
#10
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
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|