|
-
Aug 16th, 2000, 08:24 PM
#1
Thread Starter
New Member
Does anyone know where i can get an encryption program tested?
I have created an encryption program, and would like to test it for encryption strenth.
Any ideas??
-
Aug 16th, 2000, 08:40 PM
#2
Fanatic Member
Post it here for a start!
if we can break it or find problems with it then your code is not good enough for a pro to be bothered with 
and if it's based on a secret algorithm that you can't post lest it compromise the security, then it fails outright
Cheers
Paul Dwyer 
Network Engineer
Aussie In Tokyo
Using Powerbasic 6 & VB6 SP4 (Please also add your VB Version to your signature!)
-
Aug 17th, 2000, 02:02 AM
#3
Thread Starter
New Member
Too Big
The reason I haven't posted it, is because it is a large
program. The Encryption Functions calls on other
information in the program. However here is the basics of my encryption.
[code]
global dKey as Double,sKey as Double,D(255) As Byte
function Encrypt(OriginalFile)
'Promt user to enter a Key: call Key(text1.text)
sfile=OriginalFile
Rnd (-dKey): Randomize dKey
xfile = sfile & ".stdenc"
Open sfile For Random As #1 Len = 1
lenfile = LOF(1)
Close
ReDim C(lenfile) As Byte, x(lenfile) As Byte
Open sfile For Binary As #1
Get #1, 1, C()
Close
y = 0
For i = 1 To lenfile
y = y + 1
y = y Mod 255 + 1
x(i) = C(i) Xor D(y)
Next i
Open xfile For Binary As #1
Put #1, 1, x()
Close
End Function
private Sub Key (x as String)
For i = 1 To (Len(x) - 1)
t = t + Asc(Mid(x, i, 1))
Next i
t = t - Asc(Mid(x, Len(x), 1))
t = t ^ 2 - t
Rnd (-t)
Randomize t
sKey = Int(Rnd * 2123234345) + 2000398
dKey = Int(sKey / 1000 + 603)
Rnd (-sKey)
Randomize sKey
For i = 1 To 255
g = Int(Rnd * 255) + 1
h = Int(Rnd * 255) + 1
D(i) = g Xor h
Next i
end sub
This is My encryption in a nutshell. In my program i have error checking and Key verification(i.e you cannot decrypt a file that is not encrypted, and the key you enter to decrypt must match the original key)
So what do you think??
-
Aug 17th, 2000, 02:35 AM
#4
Frenzied Member
There are 2 things I'm worried about here, tha most worrying is this
the key you enter to decrypt must match the original key
I'm not quite sure what it means but I suspect it means that somewhere in the encrypted file you have some information by which the progran can check to see if the key is the correct one before decrypting it, or worse the key is contained somewhere in the encrypted file.
Now Imagine I'm a hacker and have got hold of your exe. The first thing I'm going to do is decompile it and figure out what it's doing, then I change the code slightly. If your program simply takes the key out of the encrypted file and checks it against the one entred all I have to do is change the code to take the key out of the encrypted file and use it to decrypt it. If you have some way of checking the key then I'll just run every possible key through it until I get the right one.
So make sure none of this is going on in your program, the key should be kept seperate and if an incorrect key is entered it decrypts the file with that key and you get gibberish.
I can't follow your algorythm exactly I'm afraid but by the looks of it you're encrypting a byte, writing it to the file and moving onto the next byte.
So what I have to do now is modify your program to take a small part of the file (30 bytes should do) try every possible key to decrypt that part with and run it through a spell checker, If I have one that gets a few words spelled correctly I decrypt the whole file and show it to the hacker to see if it makes sense, If it doesn't I hit a continue button and it keeps trying keys.
So ideally the algo should be modified in such a way that you can't just decrypt part of the file, every byte should be decrypted using every other byte, that way there is no choice but to decrypt the whole file using every possible key.
One of the problems of encrypting using every single byte on every single byte is that it will take a long time to encrypt and decrypt files, this isn't such a bad thing, remember the longer it takes to decrypyt your file the longer it will take the hacker to crack it, especially as he has to try loads of keys before he gets it right.
-
Aug 17th, 2000, 03:06 AM
#5
Member
Here is an idea...
All I know is that trying to encrypt by replacement is a waste of time because as soon as you know the key or how it works it is worth less.
What would interesting would be scrambling things according to some number pattern
for example if the key was 7.2.8.4
the first 7 bytes would be the 7 @ beginning of the file
the next 2 " " " " 2 " end " " "
" " 8 " " " " next 8 @ the beginning of the File (ie. after the next 8 bytes after the 7 already descrambled (ie. chars (8 - 15))
" " 4 " " " " 4 @ end after the 2
then the pattern repeats with then next seven bytes coming from the beginning (sfter the 7 & 8, ie. chars 16 - 21)
and so forth...
it would be unbreakable unless you knew the pattern (passed as a string of course then broken into bytes) and you could
having the numbers of numbers in the pattern variable too...
hhmmm
if anyone tries this let me know...
Visual Basic 6 Professional Edition
Captain Pinko
also:
Turbo Pascal, Turing, QBasic
-
Aug 17th, 2000, 03:27 AM
#6
Thread Starter
New Member
Explaination
A breif explaination:
First, the key is not stored in the encrypted file. A numder, i.e. TestNum, is created in the Key( ) sub, and stored in the encrypted file.
The Key verification uses the User inputed key and the Key( ) sub to create a TestNum. If the TestNum created by Key( ) is the same as
the TestNum in the encrypted file, then the encrypted file is decrypted.
Second, the plainFile(unencrypted file) is loaded into an array.
Code:
Open sfile For Random As #1 Len = 1
lenfile = LOF(1)
Close
ReDim C(lenfile) As Byte, x(lenfile) As Byte 'Create the array
Open sfile For Binary As #1
Get #1, 1, C() 'load whole file into array
Close
The array C( ) is then encrypted.
Code:
For i = 1 To lenfile
y = y + 1
y = y Mod 255 + 1
x(i) = C(i) Xor D(y)
Next i
This method is faster than reading one byte, encrypting it, and then writing it.
Next the encrypted array x( ) is stored in a file (Encrypted file).
Code:
Open xfile For Binary As #1
Put #1, 1, x()
Close
This explaination should help you better understand how the encryption works
-
Aug 17th, 2000, 06:33 AM
#7
Addicted Member
Is it really possible to get the source code out from a .exe-file?
I thought it was secure against hacking.
Pentax
Wilhelm Tunemyr,
Swede in London
[email protected]
"Dort, wo man Bücher verbrennt, verbrennt man am Ende auch Menschen"
Heinrich Heine (1797-1856)
Pravda vítezi!
(Truth prevails!)
-
Aug 17th, 2000, 09:54 AM
#8
Frenzied Member
Decompilers are quite easy to get hold of, I think there's been at least a couple of links to VB Decompilers been posted in the last couple of days, They're a great learnng tool If you have an EXE which does some stuff you wouldn't know how to do, but they're also used for evil purposes including getting at encryption algorithms.
I've only acrually learnt this in the past couple of days (the next bit, not the decompiling bit) It came up on one of the other encryption threads.
One of the first principals of Encryption is to write your algorithm in such a way that even if someone found your code they still couldn't crack it without the key, and that they cannot determine the key without decrypting the whole file with every possible key (so you can't just decrypt part of the file and see if it makes sense.
This way you can actually show your algorithm to people and ask for any improvements without worrying that an evil person may crack it.
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
|