AES 256Bit Encryption?

Monkey Forums/Monkey Programming/AES 256Bit Encryption?

CopperCircle

(Posted 2012) [#1]

Hi, any got any good ideas on how to password encrypt string data in Monkey? I need to encrypt some data that will then be sent to a server via HTTP Post, it will then need to be received from the server and decrypted.

Thanks...

silentshark

(Posted 2012) [#2]

Would ssl be an alternative you could consider?

Dima	(Posted 2012) [#3]

How about a simple binary integer combination of string characters with key characters using XOR bitwise operator? It's straight forward enough to understand and is the foundation of very sophisticated ciphers out there.

You simply choose any key (the longer the better) and pass your string through a function that returns a digital combination of your two strings. Pass through the same function with the same password to get back the original string.

Import mojo
Function Main()
	New MyApp
End
Class MyApp Extends App
	Method OnCreate()
		Local s:String = "ENCRYPT ME"
		Print "original string: " + s
		s = Cipher(s, "password")
		Print "ciphered: " + s
	 	s = Cipher(s, "password")
		Print "deciphered: "+ s	
	End
End
Function Cipher:String(msg:String, key:String)
	Local out:Int[] = New Int[msg.Length()]
	Local ki:Int = 0
	For Local i:Int = 0 Until msg.Length()
		out[i] = msg[i]~key[ki]
		ki+=1
		If ki >= key.Length() ki = 0
	Next
	Return String.FromChars(out)
End

c.k.	(Posted 2012) [#4]

Dima, that apparently didn't work for me. What result should you see on the screen?

Dima	(Posted 2012) [#5]

For some reason Print command isn't working in html5 without mojo, so I've updated the code above to use App Class and should work now outside C++ target which I was using.

You should see a string being encrypted and de-crypted back using the same password key. Try playing around with the original string and passwords.

silentshark

(Posted 2012) [#6]

One thing to always watch out for with encryption is key management. Whilst the XOR approach (above) may be good enough, especially with a long key, if you embed that key in your Monkey program, it would be trivial for an adversary to find it through a binary editor.

CopperCircle

(Posted 2012) [#7]

Thanks, looks interesting, I guess I would have to hash the key also to stop it being found in the binary.

NoOdle

(Posted 2012) [#8]

if you embed that key in your Monkey program, it would be trivial for an adversary to find it through a binary editor.

I was worried about this when I wanted to store bank information and passwords in an app.

http://robnapier.net/blog/aes-commoncrypto-564

silentshark

(Posted 2012) [#9]

@CopperCircle ..but if you hash the key, you can't encrypt with it..

c.k.	(Posted 2012) [#10]

silentshark, what if you make your key non-English? or even make it random, so that it would not stand out in a hex editor. Could they still hack it out?

It doesn't seem you could ever protect javascript, though. :-/

What's the solution here?!

CopperCircle

(Posted 2012) [#11]

I guess I would have to create the key on the fly using the username/password and not embed it.

silentshark

(Posted 2012) [#12]

At this point I'd ask the questions

- what are you trying to do?
- how secure does this need to be?

It might be that hard-coding the key is good enough. It might be that CopperCircle's on the fly key generation is sufficient. It might be that a more secure approach is required.

c.k.	(Posted 2012) [#13]

In my case, what I want to do is store the user's name and password locally for auto-login when they start up my game.

Maybe, when they send their name/password, I could just have the server generate an auth code or something that is then stored locally. Although, if that were intercepted, could it then be used on another device for nefarious purposes? Do I need to store a device ID as well?

Ugh.

silentshark

(Posted 2012) [#14]

@ck - what about using hashing using something like MD5?

When the user sets up their account, their userid+password is hashed. This is then stored on the server, and locally by the app. For auto-login, the app just reads the hashed value and passes to the server, which checks if it knows the hash or not.

Any tampering with the hashed value (on the local device, in transit etc) will almost certainly fail. You won't have usernames and passwords going over the wire/ the air.

c.k.	(Posted 2012) [#15]

silentshark, oh yeah! hasing! duh, right? :-)

I knew there was a way. Thank you.

c.k.	(Posted 2012) [#16]

Oops. This isn't the solution I was looking for (or is it?).

The hash will still be retrievable on the user's device, which could then be used for aforementioned nefarious purposes.

Or am I not thinking this through?

For example:

mygame.com/login.php?hash=938479837873948273947

is really no better than

mygame.com/login.php?user=billyray&pwd=shd982hf982

Storing the hash on the device is no better than the user/pwd combo string.

muddy_shoes

(Posted 2012) [#17]

Protecting the password in storage is a different issue to protecting it in transit or protecting the security of the service connection.

Ultimately if a hacker has access to the device and that device has the required information to extract the password then the password can be compromised. Similarly, if the device has the info required for auto-login then the connection can be compromised. However, having the connection compromised but protecting the user's password is the better outcome.

c.k.	(Posted 2012) [#18]

I guess I'll just store the auth token received from the server upon a successful login. I wish I could associate it, on the server, to the device ID! That would be best. Unfortunately, I've read that the Android OS doesn't have a device ID. Has this information changed?

The pattern is:

1. user logs in with username + password over Internet (I should hash this and use it to validate user+pwd on server?) (http or https)
2. server returns an auth token on successful login
3. app stores auth token on local device for subsequent auto login
4. auth token persists on server until log off requested by app, at such time auth token is deleted from local device

That's about as good as it gets, I guess.