Re: Deleting old AES api

[Jeffrey Walton]

On Mon, Mar 12, 2018 at 2:56 PM, Jeffrey Walton  wrote:
> On Mon, Mar 12, 2018 at 2:49 PM, Niels Möller  wrote:
>> Nikos Mavrogiannopoulos  writes:
>>
>>> #ifdef __GNUC__
>>> # define _GNUTLS_GCC_VERSION (__GNUC__ * 1 + __GNUC_MINOR__ * 100 +
>>> __GNUC_PATCHLEVEL__)
>>>
>>> # if _GNUTLS_GCC_VERSION >= 30100
>>> #  define _GNUTLS_GCC_ATTR_DEPRECATED __attribute__ ((__deprecated__))
>>> # endif
>>> #endif
>>
>> That means that __attribute__ ((__deprecated__)) was introduced in
>> gcc-3.1 ? Is that documented somewhere? I find no mention in
>> https://gcc.gnu.org/gcc-3.1/changes.html.
>
> I believe the versions for '__attribute__((deprecated (msg)))' are:
>
> * GCC 4.5
> * LLVM Clang 2.8
> * Apple Clang 4.2
>
> There is a version without 'msg' that has been around since the GCC 3
> days

Here it is. It first surfaces in the GCC 3.1.1 manual:
https://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Function-Attributes.html#Function%20Attributes

It is missing from the 2.95 and 3.0.4 manuals.

Jeff
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Deleting old AES api

[Jeffrey Walton]

On Mon, Mar 12, 2018 at 2:49 PM, Niels Möller  wrote:
> Nikos Mavrogiannopoulos  writes:
>
>> #ifdef __GNUC__
>> # define _GNUTLS_GCC_VERSION (__GNUC__ * 1 + __GNUC_MINOR__ * 100 +
>> __GNUC_PATCHLEVEL__)
>>
>> # if _GNUTLS_GCC_VERSION >= 30100
>> #  define _GNUTLS_GCC_ATTR_DEPRECATED __attribute__ ((__deprecated__))
>> # endif
>> #endif
>
> That means that __attribute__ ((__deprecated__)) was introduced in
> gcc-3.1 ? Is that documented somewhere? I find no mention in
> https://gcc.gnu.org/gcc-3.1/changes.html.

I believe the versions for '__attribute__((deprecated (msg)))' are:

* GCC 4.5
* LLVM Clang 2.8
* Apple Clang 4.2

There is a version without 'msg' that has been around since the GCC 3
days. But I can't find it either. If the 'msg' version is not
available you are usually safe to fall back to the non-msg version
with GCC. I've never seen the non-msg version break a compile.

Jeff
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Deleting old AES api

[Niels Möller]

Nikos Mavrogiannopoulos  writes:

> How widely used are these macros? Searching debian code:
> https://codesearch.debian.net/search?q=aes_set_encrypt_key=1=1
>
> seems to show gnutls (in fips140 drbg code), stoken, qemu, rdup,
> filezilla, pike, cmake, uanytun, haskell-bindings-nettle, libarchive,
> anytun, and mosh.

If we want to keep it, and still make it possible to replace
x86_64/aesni/aes-encrypt-internal.asm with three
x86_64/aesni/aesKEYSIZE-encrypt.asm, we could do that by redefining
aes_ctx as something like

struct aes_ctx
{ 
  unsigned keysize;
  union 
{
  struct aes128_ctx aes128;
  struct aes192_ctx aes192;
  struct aes256_ctx aes256;
} u;
};

and write each aes_* function as a switch on the keysize. Since we
already have the tests, that should be fairly cheap in terms of
maintenance.

Deprecation was announced with nettle-3.0, 3.5 years ago:

   The old interface, with struct aes_ctx and struct camellia_ctx, is kept
   for backwards compatibility, but might be removed in later
   versions.   (NEWS file)

but I guess noone saw any urgent need to update old code to the new
interfaces. (We never do, do we?).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Deleting old AES api (was: Re: What should nettle-3.5 be like?)

[Nikos Mavrogiannopoulos]

On Thu, 2018-02-22 at 13:51 +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> 
> 2018-02-22 13:41 GMT+03:00 Nikos Mavrogiannopoulos :
> > On Thu, 2018-02-22 at 07:54 +0100, Niels Möller wrote:
> > > ni...@lysator.liu.se (Niels Möller) writes:
> > Thanks for bringing that up. I have a quick fix for that, although
> > I no
> > longer have such systems for checking.
> 
> Do you need one? Maybe we can buy you smth. from eBay if it's not too
> costly?

The hw cost is not really a blocker. Maintenance costs are, such as,
installing everything and making sure that system is online and part of
the gnutls CI, and when something breaks (disks etc) replace it. I've
tried it before, but I gave up on that approach. If there is a cloud
provider which provides Via cpus we can most likely include it in
gnutls' CI. Otherwise I think it would be too time consuming.

regards,
Nikos

___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Deleting old AES api (was: Re: What should nettle-3.5 be like?)

[Dmitry Eremin-Solenikov]

Hello,

2018-02-22 13:41 GMT+03:00 Nikos Mavrogiannopoulos :
> On Thu, 2018-02-22 at 07:54 +0100, Niels Möller wrote:
>> ni...@lysator.liu.se (Niels Möller) writes:

> Thanks for bringing that up. I have a quick fix for that, although I no
> longer have such systems for checking.

Do you need one? Maybe we can buy you smth. from eBay if it's not too costly?


> seems to show gnutls (in fips140 drbg code), stoken, qemu, rdup,
> filezilla, pike, cmake, uanytun, haskell-bindings-nettle, libarchive,
> anytun, and mosh.
>
> That seems to be quite a popular API and removing it would break those
> projects. Why not keep it as backwards compatible and mark it as
> deprecated with a macro (copied from gnutls):

Dropping API is always painfull. Maybe it can be verbally deprecated now
and removed before 4.0 in future?

It is not possible to deprecate a macro. Deprecation attributes are handled
by compiler, while macros are resolved by preprocessor.

>
> #ifdef __GNUC__
> # define _GNUTLS_GCC_VERSION (__GNUC__ * 1 + __GNUC_MINOR__ * 100 +
> __GNUC_PATCHLEVEL__)
>
> # if _GNUTLS_GCC_VERSION >= 30100
> #  define _GNUTLS_GCC_ATTR_DEPRECATED __attribute__ ((__deprecated__))
> # endif
> #endif



-- 
With best wishes
Dmitry
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Deleting old AES api (was: Re: What should nettle-3.5 be like?)

[Nikos Mavrogiannopoulos]

On Thu, 2018-02-22 at 07:54 +0100, Niels Möller wrote:
> ni...@lysator.liu.se (Niels Möller) writes:
> 
> > > 2. Delete the old aes_* interface, in favor of aes128_, aes192_*
> > > and
> > >aes256_*.
> > 
> > I've now made a branch for this, delete-old-aes.
> 
> And it seems building gnutls with this branch fails, see
> https://gitlab.com/gnutls/nettle/-/jobs/53760965
> 
>   aes-padlock.c: In function 'padlock_aes_cipher_setkey':
>   aes-padlock.c:65:17: error: storage size of 'nc' isn't known
> struct aes_ctx nc;
>^~
> 
> It's great to have that ci job set up.

Thanks for bringing that up. I have a quick fix for that, although I no
longer have such systems for checking. I dropped AES-192 accelerated
support as part of that patch as well.
https://gitlab.com/gnutls/gnutls/merge_requests/602

How widely used are these macros? Searching debian code:
https://codesearch.debian.net/search?q=aes_set_encrypt_key=1=1

seems to show gnutls (in fips140 drbg code), stoken, qemu, rdup,
filezilla, pike, cmake, uanytun, haskell-bindings-nettle, libarchive,
anytun, and mosh.

That seems to be quite a popular API and removing it would break those
projects. Why not keep it as backwards compatible and mark it as
deprecated with a macro (copied from gnutls):

#ifdef __GNUC__
# define _GNUTLS_GCC_VERSION (__GNUC__ * 1 + __GNUC_MINOR__ * 100 +
__GNUC_PATCHLEVEL__)

# if _GNUTLS_GCC_VERSION >= 30100
#  define _GNUTLS_GCC_ATTR_DEPRECATED __attribute__ ((__deprecated__))
# endif
#endif


#ifndef _GNUTLS_GCC_ATTR_DEPRECATED
#define _GNUTLS_GCC_ATTR_DEPRECATED
#endif
?

regards,
Nikos

___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs