Re: lxyssl, aes and rsa questions

[Valerio Schiavoni <valerio.schiavoni@...>]

Hello Gary,

thanks for the info.

Indeed i was able to use that variant to encrypt blocks of anysize. Now, there's something very strange happening, regarding key length.

I have this code right now which works fine when the keylength is exactly 16 chars (i guess it's for aes128):

http://pastie.org/private/tg0nsen5pcuqdr79ad6cuq

Now, if I change to any other value the keylenght (line 35), I get this error:

xyssl.aes: key not long enough for selected bits length

How do you get around this? 

Thanks 

On Thu, May 27, 2010 at 4:19 PM, gary ng <garyng2000@yahoo.com> wrote:

I haven't used it for a while but the raw encryption does need 16 bytes block. A better choice for aes is the cbc and cfb variant which is also more secure.

--- On Thu, 5/27/10, Valerio Schiavoni <valerio.schiavoni@gmail.com> wrote:

From: Valerio Schiavoni <valerio.schiavoni@gmail.com>
Subject: lxyssl, aes and rsa questions
To: "Lua list" <lua@bazar2.conectiva.com.br>
Date: Thursday, May 27, 2010, 5:20 PM

Hello,

i'm using the Lua bindings for the xyssl (polarssl) for aes and rsa. 

An example of code is at http://code.google.com/p/luaxyssl/source/browse/trunk/test/test.lua?spec=svn66&r=66

AES-question)

i'm getting this error:

xyssl.aes: data must be in 16 byte multiple

local vote    = "www.timesnewyork.com"

local aes_key = 'abcdabcdabcdabcd"

local aes_crypted_vote = lxyssl.aes(aes_key):encrypt(vote)

i don't understand why. Ideas? Is the library supposed to work for any input data? Should I handle padding myself?

RSA-question)

the code snippet shows some RSA related code:

a=lxyssl.rsasign('abc')

assert(lxyssl.rsaverify('abc', a))

a=lxyssl.rsaencrypt('abc')

assert(lxyssl.rsadecrypt(a)=='abc')

I don't get how this is meant to be used with private/public key pairs generated locally, by openssl.

Currently I've implemented by own RSA code, handling the parsing of keys, exponents, padding and etc. But, I'd more than happy to re-use something that is probably less error-prone.

Thanks for any suggestion.

Valerio