Simple Lua based Encryption and Decryption (Developers)
36 replies, posted
[release]
[B]Usage[/B]
convert(string,table,boolean)
The first argument should be the string to be encrypted.
The second argument is a table filled with 5 values.
The true for encrypt and false for decrypt.
[QUOTE="Note"]The keys 1-4 in the table will be used as a 'seed' for the encryption. The 5th key will be used to add extra random characters into the string.[/QUOTE]
[b]Example[/b]
[lua]
local str = "This is an encrypted string.";
local enc1 = {124,532,123,22,0};
local enc2 = {124,532,123,22,20};
print("Encryption 1: " .. crypt(str,enc1));
print("Encryption 1: " .. crypt(str,enc2));
print("As you can see the difference between the fith argument.");
print("\nLow encryption keys close together can be insecure, here is an example.")
str = "AAA aaa";
enc1 = {1,2,3,4,0};
enc2 = {124,533,663,123,27};
print("Bad : " .. crypt(str,enc1));
print("Good: " .. crypt(str,enc2));
[/lua]
[code]
Encryption 1: .% 1Y&*=;+6#H )7J1{"Y0+0C+}K
Encryption 1: .% 1Y&*=;+6#H )7J1{"Y0+0C+}KoEjkv2?h:TM[BPzw\d-Y
As you can see the difference between the fith argument.
Low encryption keys close together can be insecure, here is an example.
Bad : CDE!cde
Good: {?]=<_}!7-l.F,*~4PoZ<\QN|;iRiFt:Al
[/code]
[/release]
[release]
[b]Encryption & Decryption Code[/b]
[lua]
local function convert(chars,dist,inv)
local charInt = string.byte(chars);
for i=1,dist do
if(inv)then charInt = charInt - 1; else charInt = charInt + 1; end
if(charInt<32)then
if(inv)then charInt = 126; else charInt = 126; end
elseif(charInt>126)then
if(inv)then charInt = 32; else charInt = 32; end
end
end
return string.char(charInt);
end
local function crypt(str,k,inv)
local enc= "";
for i=1,#str do
if(#str-k[5] >= i or not inv)then
for inc=0,3 do
if(i%4 == inc)then
enc = enc .. convert(string.sub(str,i,i),k[inc+1],inv);
break;
end
end
end
end
if(not inv)then
for i=1,k[5] do
enc = enc .. string.char(math.random(32,126));
end
end
return enc;
end
[/lua]
[/release]
I personally use this to prevent the UDP command exploit where I send the key to the user when they join and all further commands pushed by the came are then encrypted on the client, and decrypted by the server before being officially ran.
[QUOTE=zzaacckk;31312680]I personally use this to prevent the UDP command exploit where I send the key to the user when they join and all further commands pushed by the came are then encrypted on the client, and decrypted by the server before being officially ran.[/QUOTE]
Wasn't that exploit patched some time ago in a source engine update?
[QUOTE=jimbodude;31313670]Wasn't that exploit patched some time ago in a source engine update?[/QUOTE]
There is a similar one still active thats floating around, AFAIK.
This is just awful. Let's start with the part that saddens me the most, the code itself.
[lua]for inc=0,3 do
if(i%4 == inc)then
enc = enc .. convert(string.sub(str,i,i),k[inc+1],inv);
break;
end
end[/lua]
[b]->[/b]
[lua]enc = enc .. convert( str[i], k[i%4+1], inv )[/lua]
[lua]local function convert(chars,dist,inv)
local charInt = string.byte(chars);
for i=1,dist do
if(inv)then charInt = charInt - 1; else charInt = charInt + 1; end
if(charInt<32)then
if(inv)then charInt = 126; else charInt = 126; end
elseif(charInt>126)then
if(inv)then charInt = 32; else charInt = 32; end
end
end
return string.char(charInt);
end[/lua]
[b]->[/b]
[lua]local function convert( chars, dist, inv )
return string.char( ( string.byte( chars ) - 32 + ( inv and -dist or dist ) ) % 95 + 32 )
end[/lua]
Then there's your key logic. You use the key ( 124, 533, 663, 123, 27 ) in your example, but since you keep wrapping around the range 32...126, there are only 95 options available for the first four key numbers. The correct key to use would be ( 29, 58, 93, 28, 27 ). You'll see that this yields the exact same encrypted text.
Since your encryption is based around text, the random characters are completely redundant and do not add to the complexity in any way. As there are only 95^4=81450625 possible combinations for your primary key components, a dictionary attack is trivial and can be completed under a minute.
[img]http://images.overvprojects.nl/CWindowssystem32cmd.exe-2011-07-25_05.18.29.png[/img]
Oh and your description is wrong. You need to use [i]false[/i] for encryption and [i]true[/i] for decryption, not the other way around.
Thanks for the constructive criticism!
This was just ment to be a simple script that people could use for protecting invaluable data though.
What Lua. :downs:
God damn, that was a lot of harsh repliess. It looks neat, imo.
[QUOTE=jrj996;31340997]God damn, that was a lot of harsh repliess. It looks neat, imo.[/QUOTE]
Not sure if that's what you should be looking for in an encryption algorithm...
why not just use md5 though
As far as I know their are no publicly available ways to decrypt md5. All the modules are encryption.
[QUOTE=Aide;31348285]As far as I know their are no publicly available ways to decrypt md5. All the modules are encryption.[/QUOTE]
That's because md5 is not meant to be decrypted, it's a hash.
Has anyone made a encryption/decryption module for garrysmod yet?
I need one.
Overv do you mind providing the source for that program please?
[url=http://pastebin.com/v2Fi8udi]Sure[/url]. It uses 12Dicts from [url=http://wordlist.sourceforge.net/]this[/url] page.
sha512 would produce a reasonable method for signing messages but fundamentally the client has to know at some point the sign key so it's kind of moot...
[QUOTE=die_angel;31396925]sha512 would produce a reasonable method for signing messages but fundamentally the client has to know at some point the sign key so it's kind of moot...[/QUOTE]
Could use SHA-1, There is a Lua implementation of it.
Don't tell me it's insecure, I know that, buts It's more secure than the original key.
But crypting is kind of stupid, all you really need is to SIGN data to ensure it comes from a legitimate source. Crypting all the data isn't required in gmod, since you can decide "not" to send sensible data to clients that do not have the right to see them.
[QUOTE=die_angel;31429906]But crypting is kind of stupid, all you really need is to SIGN data to ensure it comes from a legitimate source. Crypting all the data isn't required in gmod, since you can decide "not" to send sensible data to clients that do not have the right to see them.[/QUOTE]
and what do you mean by sign it? add an extra argument to the command?
something in the fashion of: command+sha1(command,timestamp,secret_salt)
on the receiving end the server does the same sha1 operation with the sent command and time and see if the sha1 result match the one sent by the client. If it doesn't, just ignore the command.
like, if(client_sha1 == sha1(client_command + server_timestamp + secret_salt) )
What I ment is that entirely encoding the message and decoding it on the other side is a waste of time, you can send the message in plain text if it's not sensible data and attach to it a signature hash that will be verified on the other side. In this case the hash will only match if the time and the secret salt are the same on client and server. And the timestamp prevent to do "repeat" attacks by sending over and over a message we know to be properly signed.
Of course this is a shared key system, but i only know the basics in crypto and couldn't design for you a public key system for instance.
You are assuming that server_timestamp and timestamp are identical.
Also, if the client has access to that secret_salt (or even just for the function that generates the hash), it's pretty useless. I would say that this can't really work in GMod.
It also makes encryption useless too. But yeah.
Encryption isn't useless no matter how strong, the skiddies of gmod( Science ) will never figure out how to decrypt it on their own, and the people who know how to decrypt it or atleast give it a futile attempt, will end up cracking it anyways. This concept is for pretty much anything, not just gmod
[lua]
function Encrypt(text, pass)
local out = {}
local p = string.Explode('', pass)
local u = 1
for _,sub in ipairs(string.Explode('', text)) do
local char = string.char(Xor(string.byte(sub), string.byte(p[u])))
table.insert(out, char)
if u <= string.len(pass) then
u = 1
else
u = u + 1
end
end
return table.concat(out)
end
function Decrypt(text, pass)
local out = {}
local p = string.Explode('', pass)
local u = 1
for _,sub in ipairs(string.Explode('', text)) do
local char = string.char( Xor( math.BinToInt(sub), string.byte(p[u]) ) )
table.insert(out, char)
if u <= string.len(pass) then
u = 1
else
u = u + 1
end
end
return table.concat(out)
end
function Xor(a, b)
return (a | b) & (-1-(a & b))
end
[/lua]
It's not dumb, it's true, all encryption will do is slow a good cracker down, not stop them completely.
[QUOTE=tinu-c;31480533]It's not dumb, it's true, all encryption will do is slow a good cracker down, not stop them completely.[/QUOTE]
But a good encryption (AES 256) will slow a cracker down so much they won't be able to crack it within their, or their children or their grandchildrens lifetime.
[QUOTE=TGiFallen;31481047]But a good encryption (AES 256) will slow a cracker down so much they won't be able to crack it within their, or their children or their grandchildrens lifetime.[/QUOTE]
If they had the resources, they could crack AES.
This was 13 years ago, [URL]http://en.wikipedia.org/wiki/EFF_DES_cracker[/URL] , processor technology has come a LONG way since then and processors have also become faster and cheaper. Imagine if you spent $1 Million USD today on building one of those macienes. You could get about 65k GHz in processing power. That DES cracker tested over 90 billion keys per second. Sure it would be a challenge, but with todays technology, something could be made that could crack AES in a crackers lifetime.
Well, seeming as the key needs to be sent to the client in some form or fashion they could crack it before they even had kids, or thought about it.
[QUOTE=NickL;31506712]If they had the resources, they could crack AES.
This was 13 years ago, [URL]http://en.wikipedia.org/wiki/EFF_DES_cracker[/URL] , processor technology has come a LONG way since then and processors have also become faster and cheaper. Imagine if you spent $1 Million USD today on building one of those macienes. You could get about 65k GHz in processing power. That DES cracker tested over 90 billion keys per second. Sure it would be a challenge, but with todays technology, something could be made that could crack AES in a crackers lifetime.[/QUOTE]
You can crack everything with bruteforce. However, you seem to miss something: AES 256 uses a 256 bit key - not 56 like DES. To decrypt AES 256, that bruteforcer would need about 1606938044258990275541962092341162602522202993782792835301376 times longer. And I doubt that we got THAT far with processors yet.
Sorry, you need to Log In to post a reply to this thread.
