nettle-bugs February 2011

nettle-bugs@lists.lysator.liu.se

6 participants
5 discussions

Re: Serpent
by nisse＠lysator.liu.se 16 Apr '11

16 Apr '11

Simon Josefsson <simon(a)josefsson.org> writes: > nisse(a)lysator.liu.se (Niels Möller) writes: > >> Maybe you can try adding some of the testvectors at >> http://www.cs.technion.ac.il/~biham/Reports/Serpent/ to nettle and >> libgcrypt, and see what happens? (On the nettle side, I'll try to give >> that a reasonably high priority). > > As you noted privately, they fail in nettle but work in libgcrypt. A while ago, the email masquerading setup was broken on the machine where I write email. Because of this, the invalid adress nettle-bugs(a)lysator.liu.se has appeared in headers of some of my emails, and then copied into replies to those. The correct address is nettle-bugs(a)lists.lysator.liu.se. > According to Eli's page and the AES submission paper, there is Serpent-0 > and Serpent-1 and the paper discuss (page 22-23) that the key schedule > has changed. Do you think nettle's implementation is serpent-0, or is it just broken? I'm puzzled, because I'm fairly sure I got the test vectors from serpent's submission package (I could try to double check that), which if I understand correctly ought to be serpent-1. I vaguely remember I had some difficulty understanding the organization of the test data, though. And I'm sorry if you have wasted some time debugging fully correct key scheduling. > I updated the wikipedia article on this: > http://en.wikipedia.org/wiki/Serpent_%28cipher%29 Hmm, I can't find any mention of serpent-0 there? > Still, I'm not sure it is worth the time to fix Serpent in Nettle. I > suggest to remove it, that will save some code size as well. It's clearly no use to keep the current broken implementation. But I think it would be nice to have serpent, for a couple of reasons: * It's generally good to have a couple of ciphers with aes-compatible key and block sizes. Besides aes/rijndael and serpent, there's twofish and camellia. * I'm not sure what performance one can get out of serpent compared to aes, in particular on 64-bit processors. AES doesn't fit well with 64-bit operations, camellia is better in that respect but includes some awkward operations (current 64-bit code could perhaps be improved abit using larger tables). * I'd prefer to not remove existing features. If you have a half-done port of libgrypt's serpent code, maybe you or I could finish it? I'll start by looking into the test vectors, I'd like to figure out where nettle's came from, and I'd like to have a serpent-test.c including correct test vectors, even if we end up removing all other serpent code. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

5 11

nettle documentation tweaks?
by Daniel Kahn Gillmor 28 Feb '11

28 Feb '11

hi nettle folks-- i've been reading the latest nettle docs [0], and i wanted to say that they are excellent. Clear explanations, and useful contextual help about how various crypto primitives can be used in real-world settings as well. Thanks for this! I have two nit-picks that i'd like to share in hopes of making excellent documentation even better. 0) avoid replay attacks in pubkey authorization example. Section 6.5 contains the following paragraph: > Besides signing meaningful messages, digital signatures can be used for > authorization. A server can be configured with a public key, such that > any client that connects to the service is given a random nonce > message. If the server gets a reply with a correct signature matching > the nonce message and the configured public key, the client is granted > access. So the configuration of the server can be understood as “grant > access to whoever knows the private key corresponding to this > particular public key, and to no others”. This simple scheme is actually vulnerable to a replay attack: an man-in-the-middle attacker can pose as the service to the user while simultaneously connecting to the service directly. The attacker gets a nonce from the server, passes it to the user for signing, returns the user's response to the service, and gains access. One way to avoid this is to ensure that the "random nonce" to be signed by the user is actually a negotiated value that neither party can fully control. I recognize that this documentation shouldn't go into deep detail here, but i've seen real-world attempts to implement cryptosystems that are subject to this kind of replay attack :(. i think it would be a good idea to warn against it somehow. 1) "bad things may happen", "a few subtle issues", etc. should have outbound links There are several places in the docs that mention potential security concerns implementators should be aware of. For example, the remark about CBC providing "information leakage" could link to http://www.kb.cert.org/vuls/id/958563 Again, i'm not pushing for major changes or lots of intrusive commentary here (and i don't know how difficult it is to make outbound links in the documentation system used by nettle) but it would make already good docs even better. Thanks again for this library! Regards, --dkg [0] http://www.lysator.liu.se/~nisse/nettle/nettle.html#Cipher-modes

2 1

Re: LGPL blowfish
by nisse＠lysator.liu.se 10 Feb '11

10 Feb '11

[ Resend, the posting originally used an incorrect list address. /nisse ] Simon Josefsson <simon(a)josefsson.org> writes: > I wonder which of nettle or libgcrypt is correct -- and further, I > really wonder if anyone cares at all about Serpent if a problem like > this haven't been noticed before? Interesting... As far as I recall the nettle history (and also looking at the comments), the nettle adaptation of serpent.c was done by Rafael Sevilla, if I have touched that code I think it's trivial changes only. And I think that I wrote serpent-test.c, based on the test vectors in the serpent AES-competition package. I don't remember if I have ever done any interoperability testing of serpent with lsh (which uses nettle's implementation). Trying to connect to some openssh servers, it seems they don't enable serpent by default. Maybe you can try adding some of the testvectors at http://www.cs.technion.ac.il/~biham/Reports/Serpent/ to nettle and libgcrypt, and see what happens? (On the nettle side, I'll try to give that a reasonably high priority). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: LGPL blowfish
by nisse＠lysator.liu.se 10 Feb '11

10 Feb '11

[ Resending, got list address wrong first time. ] Simon Josefsson <simon(a)josefsson.org> writes: > nisse(a)lysator.liu.se (Niels Möller) writes: > >> Simon Josefsson <simon(a)josefsson.org> writes: >> >>> I'll look at serpent next. >> >> Great! > > Turns out it was a bit more complicated, will debug some more... BTW, how far did you get with serpent? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

GCM mode and GMAC
by nisse＠lysator.liu.se 10 Feb '11

10 Feb '11

Hi, Nikos Mavrogiannopoulos have been looking into support for Galois Counter Mode (GCM), see http://www.cryptobarn.com/papers/gcm-spec.pdf My understanding of GCM is that the main point is a new MAC function which allows efficient hardware implementation. As far as I see, there's no clear advantage of using GCM instead of plain CTR mode combined with the same MAC function (applied to the plaintext). For Nettle, I think the first step ought to be to properly support the MAC function, GMAC. The most fundamental difference to other MAC functions is that it takes two input strings (besides the key). When used as a plain MAC, the second input is empty, while when used with GCM, the first input is auxillary data to be authenticated, and the second input is the cryptotext. Some questions: * Naming: Is "gmac" a good enough name? Or "ghash" (the name of the primitive which takes a key and two inputs, in the paper)? Or do we need something more verbose, like galois_mac or gmac128 or so? * Specification: It's not entirely clear to me how the spec is to be interpreted when one of the input strings is empty. The most reasonable interpretation would be that there should be zero blocks to process (n or m equal to zero). This requires some bending of the notation in equation (2), for example, with m = 0, n = 1, we should have X_0 = 0 X_1 = C_1^* · H X_2 = (X_1 + (0 || len(C))) · H and with m = 1, n = 0, X_0 = 0 X_1 = A_1^* · H X_2 = (X_1 0 (len(A) || 0)) · H Do you agree? * Interface: I think the basic use case with empty second input should be just like other MAC:s, struct gmac_ctx; /* Key size fixed to GMAC_KEY_SIZE == 16 */ void gmac_set_key(struct gmac_ctx *ctx, const uint8_t *key); void gmac_update(struct gmac_ctx *ctx, unsigned length, const uint8_t *data); void gmac_digest(struct gmac_ctx *ctx, unsigned length, uint8_t *digest); The context struct and the set_key function is essential to be able to do any optimizations using key-dependant tables. But then we need a function to mark the end of the first input and the start of the second. Name for that one? void gmac_next(struct gmac_ctx *ctx); This will pad the current input to a block boundary, and switch to using a different length counter. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 30

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs February 2011