Im planning to create an encryption procedure.
I wonder, if the file size become twice as before is it acceptable by the users?
I think with many encryption types there is little change in file size.... If the files are very small to start with and of a fixed structure there may be little point in using encryption at all depending on the algorithm you decide upon....
If the file data is very large and has to be transfered over networks such as the internet then there may be issues however if the data rarely/never leaves the computer there shouldnt be any user complaints....
Well, mine must be double the size since I guess that is the hardest method to deencrypted.
from what i have seen, encryption and compression seem to go hand-in-hand
you might want to combine the 2 into one program :P
only super-secret spy type people will be happy with doubled file-sizes
....unless, you can employ some kind of error correction that makes the file self-redundant
I've created the decryptor end the encryptor. I wonder if somebody here able to crack it. Mind to take challenge?
I wont release the source code, I will supply the .lib file.
i wouldn't try cracking an encryption unless i had to - lol
but - they'd want several files to work with
and, any hints would be appreciated :bg
Here is the exe file, if on a week no one able to crack the method, I will release the dll and I will create a folder lock.
The encrypted file is on the program directory named "Test.fef".
Quote from: dedndave
from what i have seen, encryption and compression seem to go hand-in-hand
Indeed, you typically compress it first to remove redundancy and repetitive patterns (Like character frequency in English text), and then encrypt it.
If you try to compress it after you encrypt it then you can expect it to expand as it should look like random data.
Farabi,
Your program creates a 16-bit program. ::)
Farabi, if you use not asymmetric encrypting (also known as "open key" encryption), then any algo using "secret key" encryption scheme may be cracked in short time. Especially, you let us the encryption app.
"Secret keys" ecryption might have some (small) reliability only if you compress data before encryption (as clive says already), and if nobody have your encryption program (i.e. - algorithm).
All modern encryptors, used for hard world, such as program protectors, using asymmetric encryption.
Alex
It would also be good idea to use an exe packer with your program BEFORE you post it.
Quote from: Farabi on August 17, 2010, 03:47:05 PM
Here is the exe file, if on a week no one able to crack the method, I will release the dll and I will create a folder lock.
The encrypted file is on the program directory named "Test.fef".
My favorite kind of encryption uses a "one-time book". I provide the person, with whom I'm going carry on a series of communications, a one-time book. A one-time book is nothing but an 8 GB file containing nothing but "true random" numbers. Naturally, pseudo-random numbers will not suffice.
When you send the person a message, it is in the form of a binary file. The first 4 bytes contain an unsigned integer stating the position in the one-time book you are starting at. The remaining bytes are the message XOR'ed with the one-time book starting at the specified point.
Once you've used up the one-time book, you are done with it, it is thrown away.
That pretty much amounts to an 8 GB addendum to the file or conversation which is a huge amount of information to be transmitted over a network and a far too large amount to be transferred via the internet. Without a generated file it must be transferred in its entirety and since it is discarded after use it simply adds massive overhead to the conversation. Also since the numbers are truly random the file probably has to be generated by a human, imagine typing in 8 billion numbers. In my opinion it is not practical for an encryption method. For myself I am quite satisfied with AES, a stable and so far (?) an uncrackable nut, and by the way it is a symmetric algorithm but uses large integer factorization which is the best way to fight off brute force attacks (cracking a 256 bit key is not feasible using today's computers).
This shouldn't be hard to convert to a Win32 app.
; idea3b.asm
; Last updated: Mon Sep 16 1996 See idea3c.asm for a version which
; doesn't show the password being typed
;
; Tiny IDEA Encryption Program
; Copyright (C) Fauzan Mirza 1995-96
;
; Version 3B (Optimised version)
;
; Optimized for smaller CODE size by Mark Andreas <voyageur@sky.net>
.model tiny
.code
org 100h
BuffLen equ 32768 ; File buffer size
PassLen equ 128 ; Passphrase length
Start:
call Burn
mov dx,offset Usage
mov si,80h
lodsb
or al,al ; Check if parameters specified
jz PrintUsage
lodsb
lodsb ; Get mode switch
cmp al,'-'
jz DeMode
cmp al,'+'
jz EnMode
PrintUsage:
jmp Exit
DeMode:
inc byte ptr [Mode]
EnMode:
lodsw
AddZero:
lodsb
cmp al,20h
ja AddZero
mov byte ptr [si-1],cl ; null-terminate string
mov dx,offset Enterkey
mov ah,9
int 21h ; Print message requesting key
mov dx,offset Password
mov ah,0ah
int 21h ; Get passphrase from user
mov cx,PassLen/8 ; Hash passphrase down to 128 bits
mov si,offset Passphrase
h equ Key
g equ Key+8
TandemDM:
push cx ; push block counter <0
push si ; push data <1
mov cl,4
mov si,offset g ; -- Let first half of key = second half of hash (G)
mov di,offset hashKey
rep movsw ; after: di->key+8
pop si ; si->data 1>
push si ; push data <1
call Convert ; -- Let second half of key = data
mov si,offset hashKey
push si ; push key <2
mov di,si
call Expandkey ; -- Expand key : Key = {G, data}
mov cl,4
mov si,offset h
mov di,offset w_val
push di ; push w <3
rep movsw ; -- Let W = first half of hash (H)
pop di ; di->w 3>
pop si ; si->key 2>
push si ; push key <2
call IDEA ; -- W = IDEA encrypt (W, {G,data})
mov si,di ; si->w
mov di,offset h
call doGHsub ; -- Update H with (H xor W)
pop di ; di->key 2>
pop si ; si->data 1>
push si ; push data <1
push di ; push key <2
call Convert ; -- Let first half of key = data
mov cl,4
mov si,offset w_val ; di->key+8
rep movsw ; -- Let second half of key = W
pop si ; si->key 2>
mov di,si
call Expandkey ; -- Expand key : Key = {data, W}
mov cl,4
mov si,offset g
mov di,offset g0
push si ; push g <2
push di ; push g0 <3
rep movsw ; -- Let G0 = G
pop di ; di->g0 3>
push di ; push g0 <3
mov si,offset hashKey
call IDEA ; -- G0 = IDEA encrypt (G0, {data, W})
pop si ; si->g0 3>
pop di ; di->g 2>
call doGHsub ; -- Update G with (G xor G0)
pop si ; si->data 1>
add si,8 ; data+=8
pop cx ; cx=block counter 0>
loop TandemDM ; -- Continue hashing until no more blocks
mov di,offset Key ; Expand hashed passphrase to IDEA key
call Expandkey
mov dx,0084h
mov ax,3d02h
int 21h ; Open file with R/W access
jc Errstop
xchg bx,ax
Again:
mov cx,BuffLen
mov dx,offset Buffer
mov ah,3fh
int 21h ; Read upto 32k into buffer
Errstop:
jc Error
or ax,ax ; Check if we reached EOF
jz Done
push dx ; offset Buffer
push ax ; bytes read
push bx ; file handle
; Encrypt Buffer
mov di,dx ; DI -> data (start)
add ax,7
mov cl,3
shr ax,cl
xchg cx,ax ; CX = number of blocks to encrypt
Block:
mov si,offset Key
push cx
push di ; Save current position
mov di,offset CFBBuffer ; Encrypt 8 byte CFB buffer (DI)
call IDEA
mov cx,4 ; Process 4 words
pop si ; SI -> data, DI -> CFB buffer
cmp byte ptr [Mode],0 ; Check mode switch
jnz Decrypt
; Cipher Feedback
Encrypt:
lodsw ; Get a word from file buffer
xchg ah,al ; and convert it to little-endian
xor ax,word ptr [di] ; XOR data with CFB buffer
stosw ; Replace ciphertext in CFB buffer
xchg ah,al ; Convert back to big-endian
mov word ptr [si-2],ax ; and store in file buffer
loop Encrypt
jmp short DoNextBlock ; Skip over Decrypt routine
Decrypt:
mov bx,word ptr [di] ; Get word from CFB buffer
lodsw ; Get word from file buffer
xchg ah,al ; convert it to little-endian
stosw ; Update CFB buffer
xor bx,ax ; XOR data with CFB buffer
xchg bh,bl ; Convert back to big-endian
mov word ptr [si-2],bx ; and store in file buffer
loop Decrypt
DoNextBlock:
mov di,si ; Update block counter
pop cx
loop Block ; Continue until all blocks processed
; Buffer Encrypted
pop bx ; file handle
pop dx
push dx ; bytes read
neg dx
dec cx ; CX = FFFF
mov ax,4201h
int 21h ; Seek backwards
pop cx ; bytes read
pop dx ; offset Buffer
mov ah,40h
int 21h ; Write encrypted buffer
jnc Again ; Continue until no more data
Error:
mov dx,offset Message
Exit:
mov ah,09
int 21h ; Display message
Done:
call Burn ; Burn evidence
int 20h ; Exit
Burn:
xor ax,ax
mov di,offset Passphrase-1
mov cx,Buffer-Passphrase+BuffLen+1
rep stosb ; Overwrite data area
ret
; Convert string to little-endian words
; (called by Tandem DM hashing routine)
Convert:
mov cl,4
CopyLoop:
lodsw
xchg ah,al
stosw
loop CopyLoop
ret
; XOR update 64-bit buffer
; (called by Tandem DM hashing routine)
doGHsub:
mov cx,4
doGHloop:
lodsw
xor ax,[di]
stosw
loop doGHloop
ret
; Expand user key to IDEA encryption key
; Entry: si -> userkey, di -> buffer for IDEA key (can equal si)
; Exit: di -> IDEA key
Expandkey:
add di,16
mov bl,8
Rotate:
mov ax,bx ; Determine which two of the previous
and al,7 ; eight words are needed for this
cmp al,6 ; key expansion round
mov ax,word ptr [di-14]
mov dx,word ptr [di-12]
jb Update
mov dx,word ptr [di-28]
jz Update
mov ax,word ptr [di-30]
Update:
mov cl,9
shl ax,cl
mov cl,7
shr dx,cl ; Calculate the rotated value
or ax,dx
stosw ; and save it
inc bx
cmp bl,52
jnz Rotate ; Continue until 52 words updated
ret
; IDEA subroutine
; Entry: si -> key, di -> input data
; Exit: di -> output data, all other registers trashed
; Refer to the PGP IDEA source for a better explanation
; of the algorithm and the optimisations
; Thanks to Bill Couture <bcouture@cris.com> for speed optimisations
x0 equ bx
x1 equ cx
x2 equ bp
x3 equ di
IDEA:
mov byte ptr [Rounds],8 ; Eight rounds
push di
mov dx,word ptr [di]
mov x1,word ptr [di+2]
mov x2,word ptr [di+4]
mov x3,word ptr [di+6] ; note that DI is over-written last
Round:
call MulMod
xchg x0,ax ; x0 *= *key++
lodsw
add x1,ax ; x1 += *key++
lodsw
add x2,ax ; x2 += *key++
mov dx,x3
call MulMod
xchg x3,ax ; x3 *= *key++
push x1 ; s0 = x1
push x2 ; s1 = x2
xor x2,x0 ; x2 ^= x0
xor x1,x3 ; x1 ^= x3
mov dx,x2
call MulMod
add x1,ax ; x2 *= *key++
xchg x2,ax ; x1 += x2
mov dx,x1
call MulMod
add x2,ax ; x1 *= *key++
xchg x1,ax ; x2 += x1
xor x0,x1 ; x0 ^= x1
xor x3,x2 ; x3 ^= x2
pop dx
pop ax
xor x1,dx ; x1 ^= s1
xor x2,ax ; x2 ^= s0
mov dx,x0
dec byte ptr [Rounds] ; Continue until no more rounds
jnz Round
call MulMod
xchg x0,ax ; x0 *= *key++
lodsw
add x2,ax ; x2 += *key++
lodsw
add x1,ax ; x1 += *key++
mov dx,x3
call MulMod ; x3 *= *key++
pop di
push di
xchg x0,ax
stosw
xchg x2,ax ; unswap x1, x2
stosw
xchg x1,ax
stosw
xchg x0,ax
stosw
pop di
ret
; Multiplication modulo 65537
; ax = [si] * dx
MulMod:
push dx
lodsw
mul dx
sub ax,dx
pop dx
jnz NotZero
inc ax
sub ax,word ptr [si-2]
sub ax,dx
ret
NotZero:
adc ax,0
ret
; Data used by main program
Usage:
db "IDEA +/- <File>",36
EnterKey:
db "Enter key: ",36
Message:
db "File Error",36
Password:
db PassLen,?
Passphrase:
db PassLen dup (?)
Mode:
db ?
; Data used by IDEA routine
Rounds:
db ?
db ? ; Comment out if assembly inserts NOP
even
; Data used by Tandem DM hashing routine
Key:
dw 8 dup (?)
w_val:
dw 4 dup (?)
g0:
dw 4 dup (?)
hashKey:
dw 52 dup (?)
; Data used by CFB routine
CFBBuffer:
db 8 dup (?)
; Data buffer
Buffer:
db BuffLen dup (?)
end Start
Quote
All modern encryptors, used for hard world, such as program protectors, using asymmetric encryption.
Don't forget that a lot of them use symmetric key encryption but secure the keys with asymetric key encryption & signing. Symmetric key encryption means smaller keys with the same level of security and then the asymetric key encryption & signing offer the symmetric key some security.
HR,
Ghandi
I dont get the "Asymetric" term, what is that?
Quote
Symmetric vs. asymmetric algorithms
When using symmetric algorithms, both parties share the same key for en- and decryption. To provide privacy, this key needs to be kept secret. Once somebody else gets to know the key, it is not safe any more. Symmetric algorithms have the advantage of not consuming too much computing power. A few well-known examples are: DES, Triple-DES (3DES), IDEA, CAST5, BLOWFISH, TWOFISH.
Asymmetric algorithms use pairs of keys. One is used for encryption and the other one for decryption. The decryption key is typically kept secretly, therefore called ``private key'' or ``secret key'', while the encryption key is spread to all who might want to send encrypted messages, therefore called ``public key''. Everybody having the public key is able to send encrypted messages to the owner of the secret key. The secret key can't be reconstructed from the public key. The idea of asymmetric algorithms was first published 1976 by Diffie and Hellmann.
Asymmetric algorithms seem to be ideally suited for real-world use: As the secret key does not have to be shared, the risk of getting known is much smaller. Every user only needs to keep one secret key in secrecy and a collection of public keys, that only need to be protected against being changed. With symmetric keys, every pair of users would need to have an own shared secret key. Well-known asymmetric algorithms are RSA, DSA, ELGAMAL.
However, asymmetric algorithms are much slower than symmetric ones. Therefore, in many applications, a combination of both is being used. The asymmetric keys are used for authentication and after this has been successfully done, one or more symmetric keys are generated and exchanged using the asymmetric encryption. This way the advantages of both algorithms can be used. Typical examples of this procedure are the RSA/IDEA combination of PGP2 or the DSA/BLOWFISH used by GnuPG.
http://www.suse.de/~garloff/Writings/mutt_gpg/node3.html
http://www.wordiq.com/definition/Asymmetric_key_algorithm
http://www.wordiq.com/definition/Symmetric_key_algorithm
HR,
Ghandi
Hi!
This is try to researching of Encryptor.exe working algo.
Algo of encryption (simplified):
repeat_until_have_data{
BYTE a;
BYTE b;
WORD encrypted;
a=get_char_of_data;
b=cyclic_get_char_of_code_including_terminator_zero(); // some code, not one command
xchg a.low_nibble,a.high_nibble; // (i.e. if byte 12h, make it 21h)
encrypted=a+b; // add passowrd_byte_code to shuffled byte_of_data
WriteFile(encrypted);
}
So, algo exchange nibbles of data byte, then add to this code of password char.
Password chars getted one-by-one, including terminator (zero byte), cyclic (i.e. when password is "ends", then get move getting pointer to start of password, etc.).
Because can occur overflows, algo using destination encrypted value as word sized.
Algo of decryption is the mirrored: substract password char, then exchange nibbles.
Farabi, no bad algo, but you may use not WORD sized destination operand. For example, encryption:
data_byte=8Fh
password_byte=73h
after exchange nibbles, data_byte have value F8h
encrypted_byte = data_byte + password_byte (total: 16Bh, but with trimming due to byte sized - 6Bh)
So, we put to file 6Bh, not 16Bh.
When decryption algo:
encrypted_data_byte=6Bh
password_byte=73h
data_byte = 6Bh - 73H (so, total results: F8h. Overflowing is not have meaning).
data_byte = data_byte with exchanged nibbles (i.e. 8Fh)
So, we put decrypted data_byte with its initial value 8Fh.
With this you may decrease output file size twice, if this is not have other meaning. And working with bytes slightly faster, than working with words.
And you can use the same buffer, if you works with bytes: read byte, encrypt it, write it to the same place to the same buffer. After encryption, write to output file the buffer, into which you read original data to.
And, using of zero terminator of password make algo more vulnerable also, but not very.
As I expect, this algo is symmetric. I also make symmetric encryption algos time ago, but this is on PB compiler for DOS.
Farabi, If you want use this algo for critical tasks - I don't recommend do this (don't take umbrage please, I say this with good reasons). But for not very critical tasks this algo is perfect (because it simple and fast).
Initially I research algo with typical data patterns, not debugging or dis-assembling it.
When algo work stand clear, I disasm EXE, and try to find something "rol" or "ror". And I found "ror" 2 times: for encryption...:
00402C8E fn_00402C8E:
00402C8E 55 push ebp
00402C8F 8BEC mov ebp,esp
00402C91 83C4F0 add esp,0FFFFFFF0h
00402C94 56 push esi
00402C95 57 push edi
00402C96 8B4D0C mov ecx,[ebp+0Ch]
00402C99 D1E1 shl ecx,1
00402C9B 51 push ecx
00402C9C E80DE4FFFF call fn_004010AE
00402CA1 8945FC mov [ebp-4],eax
00402CA4 FF7510 push dword ptr [ebp+10h]
00402CA7 E83C0F0000 call fn_00403BE8
00402CAC 8945F8 mov [ebp-8],eax
00402CAF 8B7508 mov esi,[ebp+8]
00402CB2 8B7D10 mov edi,[ebp+10h]
00402CB5 33C9 xor ecx,ecx
00402CB7 894DF4 mov [ebp-0Ch],ecx
00402CBA loc_00402CBA:
00402CBA 51 push ecx
00402CBB 0FB61431 movzx edx,byte ptr [ecx+esi] <--- get data byte
00402CBF C0CA04 ror dl,4 <--- Exchange nibbles
00402CC2 8B45F4 mov eax,[ebp-0Ch]
00402CC5 668955F2 mov [ebp-0Eh],dx <--- put data to word-sized value
00402CC9 0FB61438 movzx edx,byte ptr [eax+edi] <--- get password byte
00402CCD 660155F2 add [ebp-0Eh],dx <--- add password byte to word-sized value
00402CD1 8B45FC mov eax,[ebp-4] \
00402CD4 D1E1 shl ecx,1 |
00402CD6 668B55F2 mov dx,[ebp-0Eh] |
00402CDA 66891401 mov [ecx+eax],dx \ in total: put word-sized value to output buffer
00402CDE FF45F4 inc dword ptr [ebp-0Ch] / checking for password length, and if index is too
00402CE1 8B45F8 mov eax,[ebp-8] | big, set it to zero (in 00402CE9)
00402CE4 3945F4 cmp [ebp-0Ch],eax |
00402CE7 7605 jbe loc_00402CEE /
00402CE9 6A00 push 0
00402CEB 8F45F4 pop [ebp-0Ch]
00402CEE loc_00402CEE:
00402CEE 59 pop ecx
00402CEF 41 inc ecx
00402CF0 3B4D0C cmp ecx,[ebp+0Ch] <--- size of data in [ebp+0Ch]
00402CF3 7CC5 jl loc_00402CBA
00402CF5 8B45FC mov eax,[ebp-4] <--- in eax - pointer to buffer with encrypted
00402CF8 5F pop edi ; data, allocated in 00402C9C
00402CF9 5E pop esi
00402CFA C9 leave
00402CFB C20C00 ret 0Ch
...and Decryption algo, which starts at address 00402CFE.
So, nice work, Farabi, found this algo in big app may be not easy task, if you give to potential researcher encrypted data only.
For example, many apps use simple and small algos exactly, this make is harder to found it in listing (with statical analysing).
Alex
P.S. And, one note: I never make something illegal, all info is present for education purposes only.
P.P.S. maybe this algorithm of this app is founded already, I don't know. I write this text offline, and I don't come to forum from yestardays night (in my location). Sorry, if that.
P.P.P.S. (oh, how many "P" :) Farabi, which gdi library you use? This is your own library?
Amazing, peter was right, this is easly cracked by an advance coder. :U
Quote
which gdi library you use? This is your own library?
What GDI? The encryption lib is my creation. Never expected it could be easly cracked.
Quote from: Farabi on August 18, 2010, 08:14:57 PM
Quote
which gdi library you use? This is your own library?
What GDI? The encryption lib is my creation. Never expected it could be easly cracked.
No, I mean not encryption algo. In "P.S." I talk about other code, which contained in your app :) Maybe this is inconsequence :)
Your app contain code for working with images etc. This is your code?
Alex
Yeah, I used a template for every app I created.
Quote from: Farabi on August 18, 2010, 08:21:59 PM
Yeah, I used a template for every app I created.
Thanks, I understand now.
You have apps, which use this gdi code in work?
Alex
Oke, second challenge. This is a jpg encrypted file, can you de-encrypt it? :toothy
Brute force is the only method I guess.
Quote from: Farabi on August 18, 2010, 08:27:16 PM
Oke, second challenge. This is a jpg encrypted file, can you de-encrypt it? :toothy
Brute force is the only method I guess.
Not today, Farabi, sorry.
I do something only when I have time for this :(
Jochen and Dave know, how I "lazy", because I have very small time for my interestings.
If tomorrow I would have time, MAYBE I see this. Because today I spent more than hour to researching and writing post in English. English is not my native language (you see this, of course :), and writing so big post spent many time from me :(
I engage with your Encrypton just because I think (yesterday), what it is "symmetric", and I want to caution you against usage it in critical apps.
Alex
Quote from: Farabi on August 18, 2010, 08:27:16 PM
Oke, second challenge. This is a jpg encrypted file, can you de-encrypt it? :toothy
Brute force is the only method I guess.
Farabi, the JPEG which you posted - your avatar (130x130, created with gd-jpeg v1.0, quality: 85).
Password: "1234567" (without quotations).
Alex
P.S. I don't spent all time for this - I have some time with downloading OllyDbg2.0, so, I see your jpg :)
Alex,
Your English is better than my Russian.
About encryptions. With brute force breaking, how does one know, in the program, that the solution has been found? Dictionary searches? What if you encrypted the plaintext with one algo, then encrypted the ciphertext again with a different algo. Could it be broken? Especially if the algos were not known? Especially of you gave misleading information, like having a huge public key that was not used or not used in the way it was expected? When decrypting, the first decryption would produce random looking garbage which would then be decrypted with the second algo to produce the plaintext.
Dave.
I dont know if this post is within the rules....
"no cracking and similar activities in the guise of "Reverse Engineering", no hacking techniques or related technology and no support or help with or reference to pirated software. There will also be no links to pages that support or display any of these or any other illegal areas of coding."
Quote from: KeepingRealBusy on August 18, 2010, 09:44:12 PM
Could it be broken?
Generally.... anything can be broken :lol
Quote from: KeepingRealBusy on August 18, 2010, 09:44:12 PM
Alex,
Your English is better than my Russian.
About encryptions. With brute force breaking, how does one know, in the program, that the solution has been found? Dictionary searches? What if you encrypted the plaintext with one algo, then encrypted the ciphertext again with a different algo. Could it be broken? Especially if the algos were not known? Especially of you gave misleading information, like having a huge public key that was not used or not used in the way it was expected? When decrypting, the first decryption would produce random looking garbage which would then be decrypted with the second algo to produce the plaintext.
Dave.
Hmmm....
Dave, writing complex text in English is very hard to me. Therefore - I compose big post offline (because I can concentrate on text, which I write).
You sorry me, if I answer tomorrow?
In short words I can say: this is possible to make encryption, which take big time to breaking, but I doubt, what any encryption may be unbreakable. As you know, critical passwords is changed frequently, because using modern supercomputers can help in brute-force. Length of open-key is guarantee only some time to breaking, not unbreakableness of data.
Sorry, if I write not clear, I don't have education and degree in this, and I hard in English.
Alex
Quote from: oex on August 18, 2010, 09:54:43 PM
I dont know if this post is within the rules....
"no cracking and similar activities in the guise of "Reverse Engineering", no hacking techniques or related technology and no support or help with or reference to pirated software. There will also be no links to pages that support or display any of these or any other illegal areas of coding."
When you find "cracking" word? We talk about reliability of encryption algos, about Farabi's algo in particular.
So, we try to help to Farabi in CODING of his algo, and making it more strongness. So, we talk about coding, no "cracking".
If you read my initial post about researched algo, then you see, what it contain some not "very good" text, but I delete them due to forum rules.
Alex
P.S. and, Farabi say to us about breaking his algo himself (EDITED, sorry).
Anybody else can confirm founded password?
I think, time in Farabi location is too late, and he don't come now.
Alex
Dave, I found password for this case not by brute-force. Because for 7-char password, range of passwords is 70110209207109375 different passwords. So, even if my CPU would check 2 billions of passwords in second, I should spent "just" 1.1 year to do this.
Alex
Therefore, if us conversations in this thread is not agree with forum rules, we would don't make this.
Hutch, what you say?
We talk about Farabi's code, and HE ask about this to us himself.
And, if we found some "code" or other stuff, this is not agree with rules?
Alex
Quote from: Antariy on August 18, 2010, 10:17:00 PM
Dave, I found password for this case not by brute-force. Because for 7-char password, range of passwords is 70110209207109375 different passwords. So, even if my CPU would check 2 billions of passwords in second, I spent "just" 1.1 year to do this.
Alex
Did you calculate that range based on 8 bit characters or on the number of printable text characters?
Dave.
Quote from: KeepingRealBusy on August 18, 2010, 10:23:28 PM
Quote from: Antariy on August 18, 2010, 10:17:00 PM
Dave, I found password for this case not by brute-force. Because for 7-char password, range of passwords is 70110209207109375 different passwords. So, even if my CPU would check 2 billions of passwords in second, I spent "just" 1.1 year to do this.
Alex
Did you calculate that range based on 8 bit characters or on the number of printable text characters?
Dave.
I calculate in range ASCII table with excluding zero byte. Because in edit control in Windows, we can input all chars from codes: 1...255.
So, this is 255^7.
If this be Unicode, range is astronomical :)
Alex,
All you need is 10,000 CPUs running in parallel to speed that up.
Dave.
Quote from: KeepingRealBusy on August 18, 2010, 10:31:10 PM
Alex,
All you need is 10,000 CPUs running in parallel to speed that up.
Dave.
:bg
Where we found the sponsors? :green2
Alex
Quote from: Antariy on August 18, 2010, 10:33:19 PM
Quote from: KeepingRealBusy on August 18, 2010, 10:31:10 PM
Alex,
All you need is 10,000 CPUs running in parallel to speed that up.
Dave.
:bg
Where we found the sponsors? :green2
Alex
As they say in the CodeProject, "Come Fold With Me".
Dave.
Quote from: Antariy on August 18, 2010, 10:33:19 PM
Quote from: KeepingRealBusy on August 18, 2010, 10:31:10 PM
Alex,
All you need is 10,000 CPUs running in parallel to speed that up.
Dave.
:bg
Where we found the sponsors? :green2
Alex
Alex,
How about this:
http://www.ohgizmo.com/2007/09/03/1256-microwulf-supercomputer-smaller-than-bread-box-runs-at-2625-gigaflops/
Dave.
THat was amazing you can break the password, I guess my encryption method is sucks, or antary knowledge if far beyond.
Quote from: Antariy on August 18, 2010, 08:25:28 PM
Quote from: Farabi on August 18, 2010, 08:21:59 PM
Yeah, I used a template for every app I created.
Thanks, I understand now.
You have apps, which use this gdi code in work?
Alex
Yeah I had it.
to be paid to the person who can decode this message, written in contemporary English. I will tell you ahead of time the encryption method - a one-time book. All the computers on Earth, in tandem, could not decrypt this, if run from now until the end of time.
8819BA93FD9E27A7F4C65B8AF9758C45C9CF1E24197F7737BFFEC4C43E733218
8DC89611D7ED30929DE6A91C512C95ACC8BB2469FA6D6AD80F58C7454308E2D9
DD01277C30357DB5C875A758DF01AAC3C16B8A422CCDE72F21FEDA5373AFF416
73398F03E064E966C9163766C3E01F69D2CCF48A95341CD8854B1B2900C7E4C8
7498CDADC4081EE9690D145636BDB945CDC4FBD894515D57D9AC4E9721B0C3B0
03945082D8B22795892124041A4982642BCBAF830C140598DB2E518DC7B66F61
23F1141886437F3DA588B7D86C7C56E7D43AD9865DB37C55C500E4A75B32C719
9F5CF5C3BBFEA463D40505625FE6ECE6FE466142CC455480F7557AAD5246A1DA
E25B0C2833BF4C159B80C0763F7C3463816E81FAE52A009FCADD4896ED99CE30
F63B4B2BE8D0E6F7BA77182B741A5F9012ADE539E97969637C498617DFAF581E
F49B5931C45600663995AC6BFD97BADBEE28DD65B09D443A5CDB729E846D1A56
3F1E154658D31B14BB8D3B8D227887BA0DC177379D223367BC2FBFA05BAAF520
F6F622C5C6486009C21E09966DEA914AFAF09E5053E4F39BAD1DE835B1B3652E
DF5746758F2A899620FE0C6C2B308E61732498C7EAA3E565068BD3D26936DD47
7C558029D165D5E7FE2278F0C69367EBA55E9DD6B900793D176FFF548B5A7895
D778FF6069DF29195D10AFD52447660ADF7039AF85617684644C81A97F15EBAE
4623D6B976067AAB67AD2C70124618D2240E01C7BA9095EB71D4CCD9E127C38A
3A99D49BDCA579E490FF0FB17EFD86E62CE83B590D82BB682DFD48E748AC7D07
228E709442F0A398292B354D756AECB957FC07060D0D7710842F48007D86ED44
6274C49CFB8F9FB2AC71A1551C66081E0D2A7107CEC790AF2C6579AAC6844FE9
402F2E34CDA3FA83FB902FDB0966114D93F2293F78E90EF9C63536DC350EC002
C5322972821DF9A7B369CF27839AA6E17F0E38F59ABC38E5BEC683D57DF63DED
C673AFC95F8E611C09E827C8CE1D90E408570792B997224E729EBA0F118A3714
0D9C4F1EBC5827F7A2FD6C4C666E0906FC3EC2F5FC77F9B016B13A7A56214FDA
064719ED2A5152C59A402571D5BF938F7CC1E545F45FA3DAE48348052F9A8324
944AB9245FE1DC8339EF949119202C4B5010C4FD446C72419B6C563F77FF4502
106F0B3A8F63618A853057FACAF729CAC0F213C1CDA9F1C5D37249E9B6B3E61C
E1671368A27BCDFB6525B704F18A42136464E001FE3BF88A59BFBDC30610A67E
02ED76E2EEB46AD37C20E2EEF7C092F8002FDE973105B0AAFDB18963BBBB64B8
79E5725D4FAFD9F645D5A220F305F2B3BF9AE38CF13F0C510FEC07E989D2738C
B7AC0A35831E508905A78FDCBF1C574E6A63C217AFE2B69774C4F181B5F1E8D1
A751D0CA4FFD104E9F5AC9C0480CB2435186ED30C704BFE08D9B633914098484
0E0F5EA46630AD952D9748EA4D560B33C261F5ABE599D5CFEC9FB72E5AEA70B1
2B263D733E24EF80A699D09CE4711225625F13209AC7DE4670AAC551D10DC112
74AE7C6BA4445436CDD796B21DAB057F466724537121935E9E6C71366A9EEF75
B7148EFAF751381EB89413D527AA3CF426DDE5EDEE366093D869D003BE180459
7F65DFEBE194F81EC6D8CE298B70F82B4816A6731E61759371C734DB46CA8F99
04DBD3B81CBA289FABB341CF28D3874386BEA5EC06F40D8E53C8CD5920B26CDB
64A3C9FA6040F1FB52F2A1A2B6B8C2A605DFE7C94C05E845D1CA53C4C2D8BD69
C6AF108D11FA06B5E7D180DD7659BD3BDE8DAEC917BA5513C7FB5625DE71DDE4
C2D9420251803E06DD2F00D51CBB9C35D0A95673B7CAA6E9CA7D64CC07F3CFB4
820946A60956B0E3603536E30A17387FCED8BEDCDF47B2DB6E162BF45265432B
CA3DF5F88E119C6B2551B780DD084D6C9FA05E5E4B68CE003F37B4808D93FC7A
9FD6B59759BFB2C88F114F2960DAD3F1CF9573CA388A2F820465E71FCBD88B00
C173866C350D0FD693C4810C9BCC903064D297A53BB31BAC8248AD5DEF72EA6D
1E3BF5B4037319666F496CF6C68965D8FD41B2A9B1F52C5274E250018C036B14
C739374C7DF05A0A33C5B1739169AC0645DF9B86A70C651BEE6888F8C7AC38BB
315209B9711A0AE156CC001221D1D335E871AFAD8601AEF417948FAEA0722BD4
959F509D0547AFE26621DBFA672257AF7380BB06C0914C84DF4A916D95B497C6
95D2623E049F3F4467326A393FFB54458E7263249C154CB51F884CB65389CF06
471EB3A4EE1AD65C7139FBE1AEE7C2F20E5575FF5CA43367FCE731136D416E74
FB5FCB616F0EAAA60A91CEA7F786F507342E1B1415AC3F590A37C8E3E35E4C1F
42091D422FA25D067BD34B04F2A4F4A86B05286B4238E87FFFE3BC5D47F87A43
EAEC885D0A200BCBB2CA5CF3BC00DA465ADF75EEC4F941DABF5127447087A92A
447B77507162AEC8F76EDB5DB062366D5C63E1F7177EB511B29138EC4497925A
0896563653ABE05FDA4631DFAD9E5CEA53D883621D20A7B5AF44A1F891F7C93B
BE44783996E0A3AFCEFF8930F133D475E8A672800D12E1CFAA6ED4AF7F1FC4EA
ECEC20705DA56A3AFF8C424F613CE993B86F78355D88E059E40D543B53532466
09FABED7BA4B6AB2B05F58D8EC1905F392733487C8807653AD00B5204BB5269F
C471163CC28AC799F479FD10683F90DB7B64780042D12339C50AADB3190B5914
E484164AA8379DC0DBE31A85D67907A5A2C5A8B4C252B9BE00CEEF5859258D21
2967C678875574613BADB4C3A58F22CF7616C1DA445E56A09E7DFE9D0D0F314D
1F54DE7BBB0EB1B44538007CF60EE7C658E238E7F14705931895C2C19F013017
2BB7ED4E2E7B8DEF549CF27ABA4EDEF4715A36DA6B5D7E65A13E503A2F16AAE4
That depends on how the 'random' data was generated for the one-time book.... There will likely still be statistical hints in your encrypted message.... 1,000 years ago noone could have decoded Onan's picture.... :bg
Quote from: oex on August 19, 2010, 08:14:28 AM
That depends on how the 'random' data was generated for the one-time book.... There will likely still be statistical hints in your encrypted message.... 1,000 years ago noone could have decoded Onan's picture.... :bg
The one-time book consists of true random data generated by hardware that measures the times between successive Cesium 137 nuclear decays using a Geiger-Müller tube.
Okay I got another new great super duper method of encryption, I will take a random number based on the gravity caused by moon, and then multiply it with the clock of processor and add it with the current peak of CPU usage, but the problem is how to de encrypt it? :lol
Im running out of idea how to encrypt it. I guess I will bloat my software with a random code, or make it as a dll and then disguise is as another file and load it from memory and then I paid you all to shut up :green
I guess it will be good for bussiness.
Having a quick look at your encryption for the first example i did notice that it does not change the contents much if you change one letter of the source plaintext to encrypt. I think that it would be vulnerable to a Substitution attack. Ideally when you change one letter or one bit of the plaintext, there should be a cascade effect that changes all of the content. To do this you would need to use a block cipher, that encrypts the data based on the previous word/byte/bits. At the very basic level a simple xor would be used. But this can be combined with S-Boxes to further obfuscate.
Quote from: Farabi on August 19, 2010, 03:05:45 AM
THat was amazing you can break the password, I guess my encryption method is sucks, or antary knowledge if far beyond.
Don't exaggerate my work, this is not hard, really.
Your encryption method is NO bad, with consideration what this is your start in encryption.
You can use it for not very critical tasks. Folder lock - might be one from them, because end user is not have enough technical knowledge to break your app.
Alex
Quote from: cork on August 19, 2010, 07:14:50 AM
to be paid to the person who can decode this message, written in contemporary English. I will tell you ahead of time the encryption method - a one-time book. All the computers on Earth, in tandem, could not decrypt this, if run from now until the end of time.
No, probably we spent to this only 4,7125395124994920600970896338283e+4906 ^ 2048 years.
I think, even if you increase your prize to 11-digits number of $, you don't compensate all power of calculation :)
And, I don't know, how you assured in this, but data which you post contain very many redundant and "suspicious" semi-cyclic data. So, if big research will be done, and power computer runs the decryption (not brute-force), decryption of this is possible, theoretically.
Alex
Quote from: Farabi on August 19, 2010, 11:13:49 AM
Okay I got another new great super duper method of encryption, I will take a random number based on the gravity caused by moon, and then multiply it with the clock of processor and add it with the current peak of CPU usage, but the problem is how to de encrypt it? :lol
How? What difference? This is best encryption: even author of encryption cannot decrypt his data, so, this is same reliable in world :)
Alex
This is other "challenge" :)
Try to "decrypt" this:
"αμμ ισ ποσσιβμε"
This is phrase in *English*, which will be converted in some manner.
So, say, which phrase is this, and how they "encrypted".
Do do this "encryption" no needed in any special software, and this type of "encryption" can be strongest, than this.
For usability, I add this text to Unicode text file in archive attached to post.
Alex
all is possible ?
my Greek is a little rusty - lol
Quote from: dedndave on August 20, 2010, 02:12:06 AM
all is possible ?
my Greek is a little rusty - lol
bingo.
Quote from: dedndave on August 20, 2010, 02:12:06 AM
all is possible ?
my Greek is a little rusty - lol
Your greek is rusty but it works fine :lol
well - he threw me off by using "mu" where i would have thought it would be "lamda"
Quote from: dedndave on August 20, 2010, 02:12:06 AM
all is possible ?
my Greek is a little rusty - lol
Really, all is possible. This is true, or not? :)
This is "encryption" for fun :)
How "algo" I use, Dave? Or this is only logical substitution (which is make honour to you)?
Alex
P.S. Dave, you are good with stegano?
Alex,
I have not played much with stegano, I know what it is, I just am not interested.
Dave.
Quote from: KeepingRealBusy on August 20, 2010, 11:23:59 PM
Alex,
I have not played much with stegano, I know what it is, I just am not interested.
Dave.
To
Dave (KRB): Dave, sorry for inconvenience, I write post directed to dedndave - he "break" pharese in "greek".
Alex
i took some Greek in high school (ancient Greek - lol)
about all i remember is the alphabet (hey - a Greek-derived English word)
Quote from: fearless on August 19, 2010, 02:35:17 PM
Having a quick look at your encryption for the first example i did notice that it does not change the contents much if you change one letter of the source plaintext to encrypt. I think that it would be vulnerable to a Substitution attack. Ideally when you change one letter or one bit of the plaintext, there should be a cascade effect that changes all of the content.
To elaborate on this a little better.
A good encryption system, when using the same key but different messages to encrypt, you should only expect about 50% of the bits matching in the two outputs regardless of how small or large the change is to the message.
Essentially..
0.5 = P(message1.bit(i) = message2.bit(i))
If this doesnt hold true, then there is a big weakness in your system.
Hello guys, I guess there is no point to keep this for my self, I got no benefit if my harddisk is broken.
Even this function is just a simple one, at least it will be hard do decrypt if you are smart enough like, double the encryption, or not specifying the extension of your file, or even worse, the encrypted data, is wrote on your own file format, it will halt the cracker and wasting their precious time for a week (I Hope).
Have fun with this, and dont ask me anything if you forget the password since I had no idea to breaking it.
mAlloc proc nSize:dword
add nSize,4
invoke GlobalAlloc,GMEM_ZEROINIT or GMEM_FIXED,nSize
.if eax==0
invoke PERR
invoke MessageBox,NULL,addr mem_error,NULL,MB_OK
.endif
ret
mAlloc endp
fEncrypt proc uses esi edi lpData:dword,nDataSize:dword,lpKeys:dword
LOCAL data:dword
LOCAL keysz:dword
LOCAL cntr:dword
LOCAL key:word
mov ecx,nDataSize
shl ecx,1
invoke mAlloc,ecx
mov data,eax
invoke lstrlen,lpKeys
mov keysz,eax
mov esi,lpData
mov edi,lpKeys
xor ecx,ecx
mov cntr,ecx
loop_encrypt:
push ecx
movzx edx,byte ptr [esi+ecx]
ror dl,4
mov eax,cntr
mov key,dx
movzx edx,byte ptr[edi+eax]
add key,dx
mov eax,data
shl ecx,1
mov dx,key
mov [eax+ecx],dx
inc cntr
mov eax,keysz
.if cntr>eax
push 0
pop cntr
.endif
pop ecx
inc ecx
cmp ecx,nDataSize
jl loop_encrypt
mov eax,data
ret
fEncrypt endp
fDecrypt proc lpData:dword,nDataSize:dword,lpKeys:dword
LOCAL data:dword
LOCAL keysz:dword
LOCAL cntr:dword
LOCAL key:word
mov ecx,nDataSize
shr ecx,1
invoke mAlloc,ecx
mov data,eax
invoke lstrlen,lpKeys
mov keysz,eax
mov esi,lpData
mov edi,lpKeys
shr nDataSize,1
xor ecx,ecx
mov cntr,ecx
loop_encrypt:
push ecx
shl ecx,1
mov dx,[esi+ecx]
mov key,dx
shr ecx,1
mov eax,cntr
movzx dx,byte ptr[edi+eax]
sub key,dx
mov dx,key
ror dl,4
mov eax,data
mov [eax+ecx],dl
inc cntr
mov eax,keysz
.if cntr>eax
push 0
pop cntr
.endif
pop ecx
inc ecx
cmp ecx,nDataSize
jl loop_encrypt
mov eax,data
ret
fDecrypt endp
Here is how I used it
.if wParam==0
invoke OpenFileDialog,hWnd,hInstance,CADD("Pilih Berkas"),0
movzx ecx,byte ptr [eax]
.if ecx!=0
push eax
invoke filesize,eax
mov fsz,eax
invoke mAlloc,fsz
mov data,eax
pop ecx
push ecx
invoke read_disk_file,ecx,addr data,addr fsz2
invoke GetTextInput,hWnd,hInstance,0,CADD("Input Password"),0,addr buff
invoke fEncrypt,data,fsz,addr buff
mov data2,eax
invoke GlobalFree,data
shl fsz,1
invoke GetAppPath,addr buff
invoke SetCurrentDirectory,addr buff
pop ecx
invoke write_disk_file,CADD("Test.fef"),data2,fsz
; invoke fEncrypt,CADD("Farabi Onan"),11 ,CADD("1234567")
; mov data,eax
; invoke fDecrypt,data,22,CADD("1234567")
; invoke write_disk_file,CADD("Test.txt"),eax,11
.endif
.elseif wParam==1
invoke OpenFileDialog,hWnd,hInstance,CADD("Pilih Berkas"),addr fef
movzx ecx,byte ptr [eax]
.if ecx!=0
push eax
invoke filesize,eax
mov fsz,eax
invoke mAlloc,fsz
mov data,eax
pop ecx
invoke read_disk_file,ecx,addr data,addr fsz2
invoke GetTextInput,hWnd,hInstance,0,CADD("Input Password"),0,addr buff
invoke fDecrypt,data,fsz,addr buff
mov data2,eax
invoke GlobalFree,data
invoke GetAppPath,addr buff
invoke SetCurrentDirectory,addr buff
invoke GetTextInput,hWnd,hInstance,0,CADD("Name of File"),0,addr buff
shr fsz,1
invoke write_disk_file,addr buff,data2,fsz
.endif
.endif
Sorry cant post any project for this, I got no time so I just copy-pasted from my current code, and it is too complex for you guys. It is very embarasing if you see how bad Im coding.
if anyone is interested, i've been working on AES ciphers and they are considered practically uncrackable and have a byte to byte translation.
just released the preliminary code on the HLA forum, i can convert that to MASM syntax. code only for encryption at this point, but decryption is easy enough to implement, i just haven't had the time yet.
Thanks.
I am interested in your encryption code.
okay, but be warned that the masm syntax is compiled from hla syntax so it will be a bit hard to read.
an overview:
the Aes procedure is called to initialize the expansion table. it takes three arguments, a constant for bit size (0, 1, or 2), a pointer to the key data and the size of the key.
the Cipher procedure takes two arguments, a pointer to a 16byte source to encrypt and a pointer to a buffer to store the encryption.
[edit:updated below]
I agree with Cork here, find a secure way to send a high quality random pad of a large size to the recipient then send them messages that only have to specify the start offset of the pad. A 1 megabyte pad can be used 1000 times with unique pad sections, a larger pad can be used many more time while providing a unique pad for each message.
My own preference is a SHR XOR - XOR SHL for up and down but the technique will break the heart of supercomputers as its stats are impressive, 256^characters in the message with no method of determining which one is correct.
last one didn't print out all right. anyway, i've made a more concrete version into a library with encryption and decryption. attached is the library with sources, including a masm source compilation. i've included the hla sources since those are commented and formatted.
Sevag,
Do us a favour and put long source code blocks into a zip file as they are hard to read pasted into a forum edit window.