aes internal vs external

Hi all.

I've noticed that we got AES implementation copy-pasted from old hostapd code which
is slightly inconvenient from licensing perspective (GPLv2 vs GPLv2+ for the rest of
the code) but I'm more worried that we have security sensitive code which is probably
unmaintained for years. One can argue that AES is well-known and bug-free but I would
rather use code from library like libgcrypt (
http://directory.fsf.org/wiki/Libgcrypt#tab=Overview ) which is used by many projects
and reviewed by many eyes. On the other hand having additional dependency might be
considered as way more important problem by others. Hence before attempting to port
it I'd like to know your opinion - is it worth pursuing?

--

-- 
best regards,
Max, http://fairwaves.co

Re: aes internal vs external

Hi,

> I've noticed that we got AES implementation copy-pasted from old hostapd code which
> is slightly inconvenient from licensing perspective (GPLv2 vs GPLv2+ for the rest of
> the code) but I'm more worried that we have security sensitive code which is probably
> unmaintained for years. One can argue that AES is well-known and bug-free but I would
> rather use code from library like libgcrypt (
> http://directory.fsf.org/wiki/Libgcrypt#tab=Overview ) which is used by many projects
> and reviewed by many eyes. On the other hand having additional dependency might be
> considered as way more important problem by others. Hence before attempting to port
> it I'd like to know your opinion - is it worth pursuing?

IMHO no ... you pretty much provided the arguments yourself. AES is
not only well known but also simple and doesn't depend on any
"control" from user. It wouldn't make sense to include a SSL stack in
libosmocore but for AES, not an issue IMHO.

And for the dependencies, this is especially true when you try to use
some of the functions in raw firmwares, without an OS, avoiding deps
is paramount.

Cheers,

   Sylvain