Re: [PATCH] Add ppc64 and ppc64el to Gitlab CI

Hi, I no longer talk for the gnutls developers, but why don't you submit an MR at: https://gitlab.com/gnutls/build-images/ to add a ppc64le image? If you mention that this is used by nettle, I doubt there will be an objection to it. That way you can use it directly for testing nettle. regards,

Re: Failure of gnutls ci build

On Tue, Mar 31, 2020 at 9:41 AM Niels Möller wrote: > > Nikos Mavrogiannopoulos writes: > > > On Mon, Mar 30, 2020 at 1:23 PM Niels Möller wrote: > >> > >> The error is > >> > >> 1217 ./bootstrap: getting translations into po/.reference f

Re: Failure of gnutls ci build

On Mon, Mar 30, 2020 at 1:23 PM Niels Möller wrote: > > Hi, > > I committed a change to update nettle version numbers, which implies a > new symbol version for internal symbols. > > That seems to break the gnutls ci build, > https://gitlab.com/gnutls/nettle/-/jobs/487360242 > > The error is > >

Re: Problem with gitlab CI

68C6677. > 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 From 341f0345e36625fbee4378587ab9a9aa4eb1b

Re: Current ECC work

On Sat, Jan 25, 2020 at 4:54 PM Niels Möller wrote: > I'm thinking that maybe it's reasonalbe to make a release soon, since we > have a couple of new features, including ED448, GOSTDSA, SIV-CMAC. If we > want to focus on getting a release out, I think both the compact > representation change and

Re: Gitlab merge requests

On Wed, Jan 15, 2020 at 7:18 AM Niels Möller wrote: > > If they are you should be able to see them in Settings -> CI/CD -> Runners. > > I've now had a look. There's a section for "Group runners", which is > empty. No mention of "shared runners". There's a link to "Install a > GitLab runner"

Re: Gitlab merge requests

On Tue, Jan 14, 2020 at 1:26 PM Niels Möller wrote: > > Nikos Mavrogiannopoulos writes: > > > That's great. Does git.lysator.liu.se support shared runners for CI? > > I'm not sure what "shared runners" mean. I'm not aware of any nearby > machines runn

update CI to latest fedora image

859d819ddbdbb7cef176ec2c1ed40049b942a55a Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos Date: Fri, 3 Jan 2020 09:57:38 +0100 Subject: [PATCH 2/2] sexp-conv: ensure non-null input to strcmp() and strtol() Signed-off-by: Nikos Mavrogiannopoulos --- tools/sexp-conv.c | 6 +- 1 file changed, 5 insertions

Re: rsa too slow?

On Tue, 2019-12-03 at 08:59 +0100, Nikos Mavrogiannopoulos wrote: > On Mon, Dec 2, 2019 at 9:47 PM Niels Möller > wrote: > > > name size sign/ms verify/ms > > > rsa 20480.8881 27.1422 > > >rsa (openssl) 20481.4249 45.2

Re: rsa too slow?

On Mon, Dec 2, 2019 at 9:47 PM Niels Möller wrote: > > name size sign/ms verify/ms > > rsa 20480.8881 27.1422 > >rsa (openssl) 20481.4249 45.2295 > > > > rsa-tr 20480.4257 29.1152 > > rsa-tr (openssl) 20481.3735 46.1692 > > The

rsa too slow?

Hi, I got pinged by someone testing the performance of TLS handshakes and it seems that gnutls/nettle with RSA is significantly slower than openssl. On the other hand, secp256r1 and ed25519 are faster. (btw. both openssl and gnutls/nettle are slower than rusttls). Nevertheless the RSA caught my

Re: git clone is unreliable for nettle

On Sun, Nov 24, 2019 at 4:43 PM Tim Rühsen wrote: > > Hi Niels, > > since a while (max a few weeks), I see sporadic failures when cloning > nettle. > > E.g. when building nettle on the OSS-Fuzz platform: > > Step #1: [0m [91mfatal: unable to access >

Re: SIV-CMAC

Looks good to me, but I'm adding Mirek in CC who is using SIV-AES-CMAC for NTS/NTP implementation to verify that the final code is sufficient for this implementation. regards, Nikos On Tue, Jul 2, 2019 at 4:25 PM Niels Möller wrote: > > Nikos Mavrogiannopoulos writes: > > > I pr

Re: siv and cmac

On Thu, Jun 6, 2019 at 9:44 AM Niels Möller wrote: > > ni...@lysator.liu.se (Niels Möller) writes: > > > I think the siv code could benefit from a funtion to create a cmac > > digest in one step, without the update/digest split and the intermediate > > buffer. That would be something like > > > >

Re: ANNOUNCE: Nettle-3.5

mptions accidentally made in GnuTLS, up to and including > version 3.6.1. > > New features: > > * Support for CFB8 (Cipher Feedback Mode, processing a single > octet per block cipher operation), contributed by Dmitry > Eremin-Solenikov.

Re: siv and cmac

On Sat, Jun 1, 2019 at 10:42 AM Niels Möller wrote: > > I think the siv code could benefit from a funtion to create a cmac > digest in one step, without the update/digest split and the intermediate > buffer. That would be something like > > cmac128_message(const struct cmac128_key *key, const

Re: Add check for ECC at point 0

On Fri, May 17, 2019 at 2:24 PM Simo Sorce wrote: > > > Less copy-pasting as the numbers are smaller, the curve used really > > > makes no difference. > > > > > > Nioks, > > > is the fact we do not enable 192r1 in some distribution a problem? > > > > I replied in private previously, > > sorry,

Re: Add check for ECC at point 0

On Wed, 2019-05-15 at 10:48 -0400, Simo Sorce wrote: > On Wed, 2019-05-15 at 11:42 +0200, Niels Möller wrote: > > Simo Sorce writes: > > > > > Attached find patch that adds points checks to the ECDH test > > > case. > > > Let me know if that's ok or if you prefer a whole new test. > > > > I

Re: Release?

On Sun, May 12, 2019 at 9:45 AM Niels Möller wrote: > > Nikos Mavrogiannopoulos writes: > > > I know of one or two applications that moved to nettle once the des > > functionality was removed from libcrypt. Not sure if that's a good > > reason to keep it, they are depr

Re: Release? (was: Re: curve448 branch)

I know of one or two applications that moved to nettle once the des functionality was removed from libcrypt. Not sure if that's a good reason to keep it, they are deprecated, but removing it may make it slower to move to that version. On May 11, 2019 7:40:34 PM UTC, ni...@lysator.liu.se wrote:

Re: SIV-CMAC

35d4a 2a412a50 c3e8c47d" + "2d568e91 a38e5414 8abdc0b6 e86caf87" + "695c0a8a df4c5f8e b2c6c8b1 36529864" + "f3b84b3a e8e3676c e760c461 f3a13e83"), + SHEX(""), + SHEX("00112233 44556677 8899aa

Re: SIV-CMAC

On Thu, Apr 18, 2019 at 9:00 AM Nikos Mavrogiannopoulos wrote: > > On Wed, 2019-04-17 at 20:41 +0200, Niels Möller wrote: > > > > > > To me, this sounds like a likely source of interop problems. > > > > Since > > > > RFC > > > > 5297 is genera

Re: SIV-CMAC

setup to use the macros. I > > have kept the union > > Maybe it would be easier without using the CMAC macros. They're > intended > for convenience, so there's little point in using them where it > doesn't > bring any convenience. I do not think that avoiding them would change

Re: SIV-CMAC

On Wed, 2019-04-17 at 11:37 +0200, Nikos Mavrogiannopoulos wrote: > On Sun, 2019-04-14 at 09:33 +0200, Niels Möller wrote: > > + assert(nc->context_size <= NETTLE_MAX_CIPHER16_CONTEXT_SIZE); > > > + > > > + /* ensure we have enough size

Re: SIV-CMAC

gt; think it's a bit odd to handle the keying of the two involved cipher > contexts so differently. Done. It needed some reorganization, and cmac128_syn is still needed in an ugly simulation of the CMAC structure setup to use the macros. I have kept the union The attached version should address

Re: SIV-CMAC

On Sun, 2019-04-14 at 09:33 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > This patch adds the SIV-CMAC algorithm to nettle (an update of the > > previous attempt). It is an atypical cipher which fits into the > > encrypt_message interface. > &g

SIV-CMAC

This patch adds the SIV-CMAC algorithm to nettle (an update of the previous attempt). It is an atypical cipher which fits into the encrypt_message interface. regards, Nikos From f83c8ae6fcb40f2e7dd65309050a11d7f1ee991c Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos Date: Sat, 20 Jan

Re: FYI: fast gcm/ghash for arm neon

On Sun, 2019-03-10 at 11:38 +0300, Yuriy M. Kaminskiy wrote: > Currently ghash/gcm performance on arm in both gcrypt and nettle is a > bit abysmal: > === bench-slopes-nettle === >GCM auth | 28.43 ns/B 33.54 MiB/s 39.81 > c/B1400.2 > === bench-slopes-gcrypt === >GCM

Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks

On Sat, 2019-01-12 at 17:47 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > I attach a patch which moves everything to the latest images used > > by > > gnutls (i.e., in addition to your patch, it also moves the x86 > > builds > > to debian

Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks

On Sat, 2018-12-29 at 10:40 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > I am not at home to check but most likely a newer openssl is > > needed. You can use fedora:29 or fedora:latest > > Ok, I'm trying I attach a patch which moves everything t

Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks

-logs.storage.googleapis.com/log-8fca2d38-422a-47bf-84b5-e6fe3b6a9c73.txt On December 29, 2018 9:40:48 AM UTC, ni...@lysator.liu.se wrote: >Nikos Mavrogiannopoulos writes: > >> I am not at home to check but most likely a newer openssl is needed. >You can use fedora:29 or fedora:latest &g

Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks

On Sun, 2018-12-02 at 17:46 +0100, Tim Rühsen wrote: > > > Currently I see a several automated builds breaking. It's those > > > with > > > the latest GnuTLS (from git master) as dependency. They normally > > > pull in > > > all dependencies (nettle and others) in their latest version from > > >

Re: Static analyzer

On Fri, Jul 13, 2018 at 9:26 PM, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes: > >> Nikos Mavrogiannopoulos writes: >> >>> An assert() should be sufficient to inform it of the constraints. >> >> I've added two asserts for

Re: Static analyzer (was: Re: nettle symbols: improve map files)

On Fri, 2018-07-13 at 10:08 +0200, Niels Möller wrote: > > I've had a closer look now, and I think both are of similar type. In > eratosthenes.c, we have a bitmap initialized with > > static void > vector_init(unsigned long *vector, unsigned long size) > { > unsigned long end = (size +

Re: nettle symbols: improve map files

On Thu, 2018-07-12 at 18:04 +0200, Niels Möller wrote: > > We'll see how to deal with those failures, but I don't think they > should block merging to the master branch. > > There are also two "runner system failures", see > https://gitlab.com/gnutls/nettle/-/jobs/81332562. Can that be >

Re: nettle symbols: improve map files

On Thu, 2018-07-12 at 15:28 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > Did you push it? I don't seem to see a pipeline with the f28 build > > systems: > > https://gitlab.com/gnutls/nettle/pipelines > > History info on https://gitlab.com/gnut

Re: nettle symbols: improve map files

On Thu, 2018-07-12 at 10:37 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > Patch is attached adding the builds from gnutls (mips,arm,aarch64). > > Excellent! Now applied to the master-updates branch, together with > arm > fat fixes. Did you push

Re: nettle symbols: improve map files

On Thu, 2018-07-12 at 10:31 +0200, Niels Möller wrote: > > > btw. Note that fat-arm.c capabilities detection can be simplified > > with > > getauxval: > > > > https://community.arm.com/android-community/b/android/posts/runtime > > -detection-of-cpu-features-on-an-armv8-a-cpu > > Ok, maybe we

Re: nettle symbols: improve map files

rch64-common.c#L69 regards, Nikos From a0a05a7fa3f507179ae1f41da6b76951d002838d Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos Date: Tue, 10 Jul 2018 20:58:36 +0200 Subject: [PATCH] .gitlab-ci.yml: added cross compilation and tests on mips/aarch64/arm This utilizes the qemu-user

Re: nettle symbols: improve map files

On Sun, Jul 8, 2018 at 8:36 AM Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > The attached version only exports symbols by wildcards and combines > > patches. > > Thanks a lot. I've tried this out now (currently on master-updates > branch for testing)

Re: nettle symbols: improve map files

On Mon, 2018-06-18 at 13:53 +0200, Nikos Mavrogiannopoulos wrote: > On Sun, 2018-06-17 at 19:55 +0200, Niels Möller wrote: > > Nikos Mavrogiannopoulos writes: > > > > > I attach the current state. It does move all internal symbols > > > into > > > mult

Re: nettle symbols: improve map files

On Sun, 2018-06-17 at 19:55 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > I attach the current state. It does move all internal symbols into > > multiple internal headers > > Makes sense to me. > > > The last > > patch renames _nettle

Re: nettle symbols: improve map files

On Fri, 2018-06-08 at 13:34 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > If you mean removing them from the public headers and placing them > > in > > one (or multiple) internal ones, it makes sense to me. > > Sounds reasonable. Then i

Re: nettle symbols: improve map files

On Fri, 2018-06-08 at 10:41 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > Niels, I'm not sure however if that was your intention. Didn't you > > want to deprecate some of the _nettle symbols as well like > > _nettle_secp_256r1? > > I was thin

nettle symbols: improve map files

headers and unless we remove them, they seem to be part of the API and ABI. I also attach the script which generated the files in case you'd like to play with it. regards, Nikos From 282b9ab564d5ead13eaee928b63fabeefeaebd32 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos Date: Wed, 6 Jun

Re: symbol versioning update

On Fri, 2018-03-30 at 09:29 +0200, Niels Möller wrote: > Daniel P. Berrangé writes: > > > The traditional way is for developers to update the dependancies to > > have > > an explicit version against the library they require. eg if libvirt > > requires > > some symbol

Re: What should nettle-3.5 be like?

On Sun, 2018-03-25 at 21:22 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > > > Thank you. I've committed a fix at: > > https://gitlab.com/gnutls/gnutls/merge_requests/614 > > Good. And you'll trigger a n

Re: What should nettle-3.5 be like?

On Sun, 2018-03-25 at 10:37 +0200, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes: > > > Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > > > > > > is a bit strange. Maybe it's missing an #include > > > > ? &g

Re: What should nettle-3.5 be like?

On Mon, 2018-03-19 at 23:08 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > > > It has but the detection is done through major and minor lib > > version. > > Are they updated? > > Hmm, I'm looking at > > ht

Re: mailing list archives

On Mon, 2018-03-19 at 22:44 +0100, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes: > > > Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > > > > >  On certain occasions I was trying to link to posts in that list > > > h

Re: What should nettle-3.5 be like?

On Sun, 2018-03-18 at 16:59 +0100, Niels Möller wrote: > > > Wouldn't it make sense to remove them from the map file as > > well, and only export symbols starting with nettle_*? > > I'm considing it, but it's not trivial. A related option is to move > declarations into internal, uninstalled

mailing list archives

Hi, On certain occasions I was trying to link to posts in that list however it seems that the official archives are not updated on a reasonable frequency. For example the current archives [0] were last updated on January 4. Is it possible to increase the archive generation frequency to weekly or

Re: What should nettle-3.5 be like?

On Sat, 2018-03-17 at 17:30 +0100, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes: > > > 1. Remove the the symbols nettle_hashes and nettle_secp_384r1 and > >    friends from the interface. They should be renamed with leading > >    underscore. Important to be able to merge

symbol versioning update

Hi, When we initially introduced symbol versioning in nettle we bundled all symbols from the library in a single version. That means that new symbols added to a release like nettle_get_hashes() may cause issues like this: https://bugzilla.redhat.com/show_bug.cgi?id=1549190 The underlying issue

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

On Thu, 2018-02-22 at 13:51 +0300, Dmitry Eremin-Solenikov wrote: > Hello, > > 2018-02-22 13:41 GMT+03:00 Nikos Mavrogiannopoulos <n...@redhat.com>: > > On Thu, 2018-02-22 at 07:54 +0100, Niels Möller wrote: > > > ni...@lysator.liu.se (Niels Möller) writes: > >

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

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

Re: TMP_DECL_ALIGN

On Mon, 2018-02-19 at 15:27 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > #define ALIGN16(x) \ > > ((void > > *)(((ptrdiff_t)(x)+(ptrdiff_t)0x0f)&~((ptrdiff_t)0x0f))) > > I think I'd prefer allocating a uint6

Re: TMP_DECL_ALIGN (was: Re: [PATCH v2 1/2] Implement PSS encoding functions)

On Sun, 2018-02-18 at 22:30 +0100, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes: > > > For now, I think I'll fix this, and add a TMP_ALIGN_DECL, > > TMP_ALIGN_ALLOC. > > Below patch seems to work. Other options? > > Regards, > /Niels > > diff --git a/nettle-internal.h

Re: [PATCH v2 1/2] Implement PSS encoding functions

On Sat, 2018-02-17 at 23:55 +0100, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes: > > > Daiki Ueno writes: > > > > > I have incorporated the suggested changes here: > > > https://gitlab.com/dueno/nettle/commits/wip/dueno/rsa-padding > > > > Thanks! > > > >

Re: [PATCH 1/2] Provide wrappers around OpenSSL AES GCM

That's a nice point. Operating systems evolved to be able to obtain crash at a level which is not reflected to low level functions like abort and assert. Can that be addressed in the nettle or individual lib level or at the POSIX level with the introduction of secure-assert or so? Removing

RFC: SIV-CMAC interface [was: API for new AEAD modes]

On Sat, 2018-01-27 at 09:57 +0100, Nikos Mavrogiannopoulos wrote: > > > > But then when would generate the actual IV? When data are added > gradually, one would have to require order in the calling of > functions, > to ensure that one would generate the IV to be u

Re: cmac

On Thu, 2018-02-15 at 09:45 +0100, Nikos Mavrogiannopoulos wrote: > On Thu, 2018-02-15 at 07:53 +0100, Niels Möller wrote: > > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > > > +@acronym{CMAC} is a message authentication code based on CBC > > >

Re: cmac

On Thu, 2018-02-15 at 07:53 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > +@acronym{CMAC} is a message authentication code based on CBC > > encryption > > +mode. It is suitable for systems where block ciphers are > > pref

easier version checks

What about extending the macros in version.h with a simple to use combined version number? From e96108cbb92a923e02349a0d3b672a9b2b94c8b9 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos <n...@redhat.com> Date: Wed, 7 Feb 2018 11:29:07 +0100 Subject: [PATCH] version.h: int

Re: Performance of AESNI impl vs other crypto libraries

On Tue, 2018-01-09 at 09:17 +0100, Nikos Mavrogiannopoulos wrote: > > > in ctr_crypt contribudes quite a few cycles per byte. It would be > > > faster > > > to use an always word-aligned area, and do the copying and > > > incrementing > > > using wor

Re: API for new AEAD modes

On Wed, 2018-01-24 at 09:46 +0100, Niels Möller wrote: > > > > So then we'de have something similar to the ccm_*_message > > > functions. > > > Should the nonce length and tag length be variable per message? > > > > The tag is fixed since it is used as the IV. On the branch I'm > > working > >

Re: API for new AEAD modes

On Tue, Jan 23, 2018 at 7:34 PM, Niels Möller <ni...@lysator.liu.se> wrote: > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > >> As it is now AEAD ciphers in nettle are supported with their own API. >> AES-CCM provides: >> ccm_aes128_set_key >>

Re: cmac

On Wed, 2018-01-17 at 10:59 +0100, Nikos Mavrogiannopoulos wrote: > Thank you for the catch. Hopefully the x86 run on our CI would have > caught it but I never run it there. I've now sent a build with the > 0001 > patch at: > https://gitlab.com/nmav/nettle/pipelines/16256301 Fol

API for new AEAD modes

Hi, As it is now AEAD ciphers in nettle are supported with their own API. AES-CCM provides: ccm_aes128_set_key ccm_aes128_set_nonce ccm_aes128_update ccm_aes128_encrypt ccm_aes128_decrypt ccm_aes128_digest ccm_aes128_encrypt_message ccm_aes128_decrypt_message AES-GCM: gcm_aes128_set_key

Re: cmac

On Tue, 2018-01-16 at 14:25 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > > > On Mon, Jan 15, 2018 at 9:37 PM Niels Möller <ni...@lysator.liu.se> > > wrote: > > > > > > + unsigned overflow = b2

Re: cmac

On Mon, Jan 15, 2018 at 9:37 PM Niels Möller <ni...@lysator.liu.se> wrote: > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > Re-sending as it seems I forgot to remove cmac-internal from makefile. > > I've had a first reading, and a few comments. > Thank y

Re: cmac

On Fri, 2018-01-12 at 11:51 +0100, Nikos Mavrogiannopoulos wrote: > On Wed, 2018-01-10 at 11:24 +0100, Niels Möller wrote: > > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > > > The attached patch brings support for AES-128-CMAC. The code is >

cmac

Hi, The attached patch brings support for AES-128-CMAC. The code is based on the samba code. The rshift and lshift functions come from the AES implementation bundled with samba. regards, Nikos From e68adc5e81ff8814707cddba47118f99778deabc Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos &l

Re: Performance of AESNI impl vs other crypto libraries

On Tue, 2018-01-09 at 08:29 +0100, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes: > > > I agree CTR seems more important. I'm guessing that the loop > > > > for (p = dst, left = length; > >left >= block_size; > >left -= block_size, p +=

Re: Performance of AESNI impl vs other crypto libraries

On Thu, 2018-01-04 at 23:43 +0300, Dmitry Eremin-Solenikov wrote: > Hello, > > 2018-01-04 21:36 GMT+03:00 Niels Möller <ni...@lysator.liu.se>: > > Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > > > > > I wouldn't expect if an

Re: possible new modes

On Thu, Jan 4, 2018 at 2:02 PM, Niels Möller wrote: > What about OCB (for which RFC 7253 may be the most appropriate spec)? As > far as I'm aware, it's one of few AEAD modes which provides a > significant performance advantage over doing MAC and encryption > separately.

Re: Performance of AESNI impl vs other crypto libraries

On Thu, Jan 4, 2018 at 2:15 PM, Niels Möller <ni...@lysator.liu.se> wrote: > Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > >> If I had to chose between optimizing one of two, I'd say CTR. > > I agree CTR seems more important. I'm guessing that

Re: Performance of AESNI impl vs other crypto libraries

On Wed, Jan 3, 2018 at 7:36 PM, Niels Möller wrote: > "Daniel P. Berrange" writes: > >> I wrote a crude/simple test program to compare the performance of >> AES-128-CBC across openssl, gcrypt, nettle and gnutls, and was >> surprised to find that nettle

possible new modes (was: [PATCH v3 0/1] Add Cipher FeedBack mode support)

On Thu, Jan 4, 2018 at 2:57 AM, Dmitry Eremin-Solenikov <dbarysh...@gmail.com> wrote: > 2018-01-03 12:44 GMT+03:00 Nikos Mavrogiannopoulos > <n.mavrogiannopou...@gmail.com>: >> On Sat, Oct 7, 2017 at 8:55 PM, Dmitry Eremin-Solenikov >> <dbarysh...@gmail.com>

Re: [PATCH v3 0/1] Add Cipher FeedBack mode support

On Sat, Oct 7, 2017 at 8:55 PM, Dmitry Eremin-Solenikov wrote: > Add CFB mode support. CFB uses segment size = block size. > > Changes since V2: > > - Dropped CFB8, isn't widely used. I'm getting late into this discussion, but it seems that samba (which uses nettle and

Re: Release plan?

On Mon, Nov 6, 2017 at 7:41 PM, Niels Möller wrote: >> I suggest including the attached patches to the CI. The first makes >> sure that random errors due to installation of fedora packages don't >> get in the way by using the pre-build images used in gnutls. > > To me, it

Re: Release plan?

On Sun, 2017-11-05 at 23:42 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > The changes seem good and backwards compatible. I haven't tested > > compiling gnutls or running its test suite though. > > Let me know

Re: Release plan?

On Mon, 2017-10-23 at 22:52 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > On Thu, 2017-09-28 at 21:48 +0200, Niels Möller wrote: > > > To get minimal ABI breakage, I also suspect we would need a > > > release > &

Re: Release plan?

On Thu, 2017-09-28 at 21:48 +0200, Niels Möller wrote: > There are several unfinished projects, curve448, gost cryptos, > skein,... > > But there are also a few new features completed since the nettle-3.3 > release: rsa-pss, and hkdf. And a couple of bugfixes. And we have the > ABI problems which

Re: static analyzer results

On Wed, 2017-09-20 at 18:32 +0200, Nikos Mavrogiannopoulos wrote: > On Wed, 2017-09-20 at 17:55 +0200, Niels Möller wrote: > > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > > > On Thu, 2017-09-14 at 23:28 +0200, Niels Möller wrote: > > > >

Re: static analyzer results

On Wed, 2017-09-20 at 17:55 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > On Thu, 2017-09-14 at 23:28 +0200, Niels Möller wrote: > > > I committed a variant of this ifdef thing this morning. But the > > > gnutls >

Re: static analyzer results

On Thu, 2017-09-14 at 23:28 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > > > On Wed, Sep 13, 2017 at 9:57 PM, Niels Möller <ni...@lysator.liu.se > > > wrote: > > > Question is if the patch is more or less

Re: static analyzer results

On Wed, Sep 13, 2017 at 9:57 PM, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes: > >> Rewriting using do {} while loop would make some sense, to make it clear >> both to the analyzer and to humans that loops are intended to run at >> least once. > > With

Re: static analyzer results

On Wed, 2017-09-13 at 10:43 +0200, Niels Möller wrote: > > > The only way I could eliminate the error was through the attached > > patch which is ugly. > > Rewriting using do {} while loop would make some sense, to make it > clear > both to the analyzer and to humans that loops are intended to

Re: static analyzer results

On Wed, Sep 13, 2017 at 8:09 AM, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes: > >> This code needs some careful analysis, to see under what conditions hi >> might be used uninitialized, and in case there's some valid inputs for >> which this could happen

Re: TLS PRF + HKDF

On Wed, 2017-09-06 at 22:47 +0200, Niels Möller wrote: > ni...@lysator.liu.se (Niels Möller) writes (back in May): > > > Nikos Mavrogiannopoulos <n...@redhat.com> writes: > > > > > --- /dev/null > > > +++ b/hkdf.c > > > @@ -0,0 +1,85 @@

Re: TLS PRF + HKDF

On Wed, 2017-08-30 at 19:05 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > > > I have modified the text to be more self-contained and clarify the > > role of the variables, which may address terminology as well. Let >

Re: [PATCH] ecc-mod-arith.c: expose mpn_mul_n invariant violation

On Tue, Jul 18, 2017 at 4:57 PM, Niels Möller wrote: > Sergei Trofimovich writes: > >> Overlap happens at a call of >> ``` >> ecc_modp_mul (ecc, y3, B, z1); >> ``` >> which is basically >> ``` >> mpn_mul_n (y3, B, z1, m->size), >> ``` > I'm

Re: [PATCH] Avoid assertion failure in pss_verify_mgf1

On Fri, Jun 9, 2017 at 11:01 PM, Niels Möller wrote: > Daiki Ueno writes: > >>> If this EM is the same EM recovered when verifying the signature, then >>> it must still correspond to an integer of size at most modBits - 1. >> >> Yes, that seems to be correct,

Re: TLS PRF + HKDF

On Mon, May 22, 2017 at 12:36 AM, Niels Möller wrote: > And regarding nettle-3.3, I guess it's time to try to formulate what > the relase objectives should be. > > 1. Fix the ABI problem (which unfortunately implies an abi break). Some >progress, but I don't think I've

Re: TLS PRF + HKDF

be it would make sense to take out the first > and/or final iterations. Patch 0005 unrolls the first loop and does that change. I find that longer and not as easy to follow, but I may have not caught what you meant. The last patch adds documentation for the added functions. regards, Nikos Fr

TLS PRF + HKDF

in projects (.bootstrap is not even listed in ls). regards, Nikos From f198ab5ac4c246945d44ea54f6e218a33658c334 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos <n...@redhat.com> Date: Tue, 16 May 2017 14:30:41 +0200 Subject: [PATCH 6/6] Added the HKDF key derivation function and test vectors

static analyzer run + few fixes

-view. Both involve the ecc_mod() function and the variable 'hi'. regards, Nikos From 283da8ece01938da0bbf279050870cb017cd704f Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos <n...@redhat.com> Date: Tue, 16 May 2017 15:25:28 +0200 Subject: [PATCH 4/4] hogweed-benchmark: eliminated memor

Re: [PATCH 0/2] Implement RSA-PSS signature scheme

On Sun, 2017-03-12 at 11:21 +0100, Niels Möller wrote: > > The prototypes of the top-level functions are as follows: > > > > int > > rsa_pss_shaXXX_sign_digest_tr(const struct rsa_public_key *pub, > >   const struct rsa_private_key *key, > >   void

Re: Is the gitlab being used or not?

nterfaces. regards, Nikos From 5bfed966da2c384d0cd2e24f22437dfb70b2532a Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos <n...@redhat.com> Date: Tue, 28 Feb 2017 10:03:24 +0100 Subject: [PATCH] Made current contibution rules explicit Signed-off-by: Nikos Mavrogiannopoulos <n...@r

  1   2   3   >