Fork me on GitHub

Announcement

The oneye project has been discontinued. You might not expect further fixes and support from us. All community related systems are set to read-only mode. Though feel free to download and use oneye as-is or even fork it over at GitHub.

#1 2011-07-23 00:17:22

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Help on Advanced Encryption Standard (AES)

Hey guys,

I'm really not that familiar with encrypting and decrypting, so maybe one of you can help in this?!

In order to secure oneye 0.9 I already integrated SAWASC stage A (hiding password from sniffers on login). I don't think we'll need SAWASC stage B support.

I just extended the idea of SAWASC and got to the following point: We can encrypt all the data transfer once the user logged in using AES or a similar technique.

Can you provide me a simple way to use AES in JavaScript and PHP?

I don't want to handle IVs or what ever at all. That stuff can be fixed or what ever... Just something like:

function encrypt(data, password) {
    // do the ugly stuff here
}
function decrypt(encrypted, password) {
    // do the other ugly stuff here
}

Best regards,
Lars Knickrehm

The oneye project.

Offline

#2 2011-07-23 01:21:20

daniel
Member
From: Lisboa, Portugal
Registered: 2011-07-21
Posts: 19

Re: Help on Advanced Encryption Standard (AES)

Offline

#3 2011-07-23 02:52:13

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Re: Help on Advanced Encryption Standard (AES)

Thanks for that links, but I already knew of them.

The JS implementation uses CTR, which is not supported by the native php extension and the linked php script return different values, too.

(Yes, I base64 encoded the php script's result.)


Best regards,
Lars Knickrehm

The oneye project.

Offline

#4 2011-07-23 06:22:32

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Re: Help on Advanced Encryption Standard (AES)

It's done - at least the first step tongue ...

I got SlowAES (see http://code.google.com/p/slowaes/ ) to work on JS and PHP side. The JS side required two patches and finally I "re-ported" the PHP side.

Finally its usage got quite easy and works at least for "value" (as text) and "key" (as password). As next step I just need to integrate it into oneye 0.9 to be optionally used for data transfers.

One more question to the encryption geeks: What is the IV used for and shall I use a random IV per session or can it be a zero char byte array without getting insecure?


Best regards,
Lars Knickrehm

The oneye project.

Offline

#5 2011-07-23 07:15:24

amazonwebservices
Member
Registered: 2011-07-21
Posts: 28

Re: Help on Advanced Encryption Standard (AES)

This is a poor mans Encryption - set IV this way in the code or the salting will potentially slow down the code.  Pasted source best as possible.  Please note that this can be cracked fairly quick and easy for someone with a motive....nation state.

Salted to hide and unhide....


   
// Takes a password and salt as a byte array       openSSLKey: function(passwordArr, saltArr) {         
// Number of rounds depends on the size of the AES in use        
 // 3 rounds for 256        
 //              2 rounds for the key, 1 for the IV        
 // 2 rounds for 128        
 //              1 round for the key, 1 round for the IV         
// 3 rounds for 192 since it's not evenly divided by 128 bits         
var rounds = this.Nr >= 12 ? 3: 2;         
var key = [];         
var iv = [];         
var md5_hash = [];         
var result = [];         
data00 = passwordArr.concat(saltArr);         md5_hash[0] = GibberishAES.Hash.MD5(data00);         
result = md5_hash[0];        
 for (var i = 1; i < rounds; i++) {             md5_hash[i] = GibberishAES.Hash.MD5(md5_hash[i - 1].concat(data00));             result = result.concat(md5_hash[i]);         }        
 key = result.slice(0, 4 * this.Nk);        
 iv = result.slice(4 * this.Nk, 4 * this.Nk + 16);        
 return {             key: key,             iv: iv         };     },

the diff is stated

/*
*  call-seq:
*     cipher.pkcs5_keyivgen(pass [, salt [, iterations [, digest]]] ) -> nil
*
*  Generates and sets the key/iv based on a password.
*
*  WARNING: This method is only PKCS5 v1.5 compliant when using RC2, RC4-40, or DES
*  with MD5 or SHA1.  Using anything else (like AES) will generate the key/iv using an
*  OpenSSL specific method.  Use a PKCS5 v2 key generation method instead.
*
*  === Parameters
*  +salt+ must be an 8 byte string if provided.
*  +iterations+ is a integer with a default of 2048.
*  +digest+ is a Digest object that defaults to 'MD5'
*
*  A minimum of 1000 iterations is recommended.
*
*/

Last edited by amazonwebservices (2011-07-23 07:36:56)

Offline

#6 2011-07-23 07:24:33

amazonwebservices
Member
Registered: 2011-07-21
Posts: 28

Re: Help on Advanced Encryption Standard (AES)

md5_hash[0] = MD5Digest(password | salt)   
md5_hash[1] = MD5Digest(md5_hash[0] | password | salt)   
md5_hash[2] = MD5Digest(md5_hash[1] | password | salt)   
key = md5_hash[0] | md5_hash[1]  
 iv = md5_hash[2] 

as you can see the salt is used diff here in the source...

where '|' denotes concatenation.
If you need to compare it to the output of openssl use the following command line echo -n "test" | openssl enc -aes-256-cbc -a -p -k password The '-p' flag will give you back the salt, key, and iv generated by openssl.

Base64 Encoding
In order to remain compatible with OpenSSL, Base64 lines should break every 64 characters. If the Base64 encoded string is less than 64 characters, a break should be included at the end automatically. If it more than 1 line, breaks only need to be included every 64 characters, and not at the end of the last line.

I love the term salt....beef jerky

Last edited by amazonwebservices (2011-07-23 07:38:16)

Offline

#7 2011-07-23 07:28:07

amazonwebservices
Member
Registered: 2011-07-21
Posts: 28

Re: Help on Advanced Encryption Standard (AES)

static VALUE
ossl_cipher_pkcs5_keyivgen(int argc, VALUE *argv, VALUE self)
{
    EVP_CIPHER_CTX *ctx;
    const EVP_MD *digest;
    VALUE vpass, vsalt, viter, vdigest;
    unsigned char key[EVP_MAX_KEY_LENGTH], iv[EVP_MAX_IV_LENGTH], *salt = NULL;
    int iter;

    rb_scan_args(argc, argv, "13", &vpass, &vsalt, &viter, &vdigest);
    StringValue(vpass);
    if(!NIL_P(vsalt)){
        StringValue(vsalt);
        if(RSTRING_LEN(vsalt) != PKCS5_SALT_LEN)
            rb_raise(eCipherError, "salt must be an 8-octet string");
        salt = (unsigned char *)RSTRING_PTR(vsalt);
    }
    iter = NIL_P(viter) ? 2048 : NUM2INT(viter);
    digest = NIL_P(vdigest) ? EVP_md5() : GetDigestPtr(vdigest);
    GetCipher(self, ctx);
    EVP_BytesToKey(EVP_CIPHER_CTX_cipher(ctx), digest, salt,
                   (unsigned char *)RSTRING_PTR(vpass), RSTRING_LEN(vpass), iter, key, iv); 
    if (EVP_CipherInit_ex(ctx, NULL, NULL, key, iv, -1) != 1)
        ossl_raise(eCipherError, NULL);
    OPENSSL_cleanse(key, sizeof key);
    OPENSSL_cleanse(iv, sizeof iv);

    return Qnil;
}

ruby....I like this...you can see iv use better here in salt

Offline

#8 2011-07-24 07:08:57

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Re: Help on Advanced Encryption Standard (AES)

Thanks guys, I finally integrated AES encrypted transfers after SAWASC login. There's just one problem: When reloading the page, JavaScript looses the saved key for encrypting and decrypting. Sending the key back to the refreshed client would create a build in security problem, so I decided to create a window id and there's one key (and iv) per window. When reloading (respectively opening a new tab or window) the connection won't be encrypted unless the user logs in again. Later there could be a warning showing the password box.

But what's encrypted and what's not?
Both, requests and responses are encrypted, but file transfers are not. That means: It'd still be possible to steal data from all objects, which get downloaded and thanks to loaded scripts and styles and displayed images it'd be possible to create a list of launched packages.

All in all this is a solution thought for HTTP only, whereas HTTPS offers better security.

PS: As side effect it's possible to recognise each window, thanks to the window id smile !


Best regards,
Lars Knickrehm

The oneye project.

Offline

#9 2011-07-24 13:22:03

daniel
Member
From: Lisboa, Portugal
Registered: 2011-07-21
Posts: 19

Re: Help on Advanced Encryption Standard (AES)

You can encrypt the requests of the file transfers and so it wouldn't be possible to understand which packages it would correspond to...

Furthermore, if you only not encrypt images and other binary data, but encrypt a file transfer if it's text, then the cracker won't even be able to understand if it's encrypted or not (I don't know how that works, I'm just assuming you're using a good encryption algorithm)

Offline

#10 2011-07-24 19:04:48

amazonwebservices
Member
Registered: 2011-07-21
Posts: 28

Re: Help on Advanced Encryption Standard (AES)

anyone ever just think about https as a quick and simple way to handle the hole thing

Offline

#11 2011-07-24 22:53:28

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Re: Help on Advanced Encryption Standard (AES)

daniel wrote:

You can encrypt the requests of the file transfers and so it wouldn't be possible to understand which packages it would correspond to...

Responses will be encrypted, but files, which need to be downloaded cannot, can they? I'd need to encrypt the data with JavaScript on the client side before showing the browser's download dialog...

daniel wrote:

Furthermore, if you only not encrypt images and other binary data, but encrypt a file transfer if it's text, then the cracker won't even be able to understand if it's encrypted or not (I don't know how that works, I'm just assuming you're using a good encryption algorithm)

This won't work, since I transfer the AES encrypted data base64 encoded. And even if it'd all be binary, it'd be possible to split at least 95% of the images from encrypted data. For more information on that check out http://en.wikipedia.org/wiki/File_%28command%29 .

amazonwebservices wrote:

anyone ever just think about https as a quick and simple way to handle the hole thing

Sure, but https is not available on simple servers and just as with eyeos series 1 I claim to support those servers. And additionally giving attention to higher scaled servers.


Best regards,
Lars Knickrehm

The oneye project.

Offline

#12 2011-07-24 23:50:53

amazonwebservices
Member
Registered: 2011-07-21
Posts: 28

Re: Help on Advanced Encryption Standard (AES)

Agree.  This is just another reason we need to move fast to large scale support on cloud systems.  Lars - how much computing power or users do you expect to have on your application?

Servers and clouds. 

I suggest we start to split the OS into 4 categories of use

1. SOC - Small office cloud  1-10 users   -  This is usually the same as a share server - 4 proc high end dell with tons of mems
2. LOC - Large office cloud  11 - 99 users - This is usually a dual proc dedicated servers - mid range.
3. ESC - Enterprise Service Cloud 100 - 200 + users - 8 proc high end server dedicated.
4. MIC - Multiple Instance Cloud  201 + users - starts at 4#  8+ proc servers running load balance software and such.

The cloud systems we are buildin have load balance at all levels and unlimited storage with a CDN.....the most important part.

From that point we can begin to fit the specific features of everyones versions of the software into categories.

Offline

#13 2011-07-26 22:49:05

daniel
Member
From: Lisboa, Portugal
Registered: 2011-07-21
Posts: 19

Re: Help on Advanced Encryption Standard (AES)

lars-sh wrote:
daniel wrote:

You can encrypt the requests of the file transfers and so it wouldn't be possible to understand which packages it would correspond to...

Responses will be encrypted, but files, which need to be downloaded cannot, can they? I'd need to encrypt the data with JavaScript on the client side before showing the browser's download dialog...

No, I meant the request, the params that the browser send to the server.

Offline

#14 2011-07-27 01:43:01

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Re: Help on Advanced Encryption Standard (AES)

daniel wrote:

No, I meant the request, the params that the browser send to the server.

lars-sh wrote:

Both, requests and responses are encrypted, but file transfers are not.


Best regards,
Lars Knickrehm

The oneye project.

Offline

Board footer

Powered by FluxBB