nettle-bugs

nettle-bugs@lists.lysator.liu.se

3 participants
2194 discussions

typo in manual for arctwo
by Daniel Kahn Gillmor 21 Mar '11

21 Mar '11

Hi Nettle folks-- There's a typo in the Nettle manual about the ARCTWO block size. the attached patch (against 2.1) should fix it. Of course, it might already be fixed on the development trunk. Is there a public revision control system for nettle someplace i can look at? --dkg PS i sent this message earlier PGP/MIME-signed, but it was rejected by the mailing list with "After content filtering, the message was empty" -- could the content filtering be relaxed a little bit to allow multipart/signed messages? The message MIME structure looked like this: └┬╴multipart/signed ├┬╴multipart/mixed │├╴text/plain │└╴text/x-diff attachment └╴application/pgp-signature attachment I then tried re-sending it without the cryptographic signature, which produced a message like this: └┬╴multipart/mixed ├╴text/plain └╴text/x-diff attachment This second message was rejected with the message: "The message's content type was not explicitly allowed" Both of these seem like pretty reasonable message structures for posts to a cryptographic software development mailing list; it'd be nice if they could go through :) Here is the patch inline: arctwo-doc-fix.patch --- nettle.texinfo.orig 2011-03-16 19:08:50.000000000 -0400 +++ nettle.texinfo 2011-03-16 19:09:26.000000000 -0400 @@ -871,7 +871,7 @@ @end deftp @defvr Constant ARCTWO_BLOCK_SIZE -The AES block-size, 8 +The ARCTWO block-size, 8 @end defvr @defvr Constant ARCTWO_MIN_KEY_SIZE

2 4

nettle perl bindings
by Daniel Kahn Gillmor 18 Mar '11

18 Mar '11

Hi Nettle Folks-- I'm building Perl bindings for libnettle. I hope to claim the Crypt::Nettle namespace. The project is in its infancy, but i currently have coverage for all hash functions and ciphers. My next steps are adding bindings for Yarrow and RSA. At the moment, my source code is available via git: git clone git://lair.fifthhorseman.net/~dkg/libcrypt-nettle-perl You can test it with: cd libcrypt-nettle-perl perl Makefile.PL make make test You can read the docs with: pod2text lib/Crypt/Nettle.pm pod2text lib/Crypt/Nettle/Hash.pm pod2text lib/Crypt/Nettle/Cipher.pm I have not yet uploaded it to CPAN. I'd be very happy to get feedback from anyone interested. Regards, --dkg

4 13

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 11 Feb '11

11 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

elliptic curve in nettle?
by Daniel Kahn Gillmor 07 Jan '11

07 Jan '11

Hey Niels and other Nettle folks-- Have you given any thought about adding elliptic curve cryptography to nettle as another public-key algorithm? There are many references for elliptic curve online (i confess i'm not up on the implementation details), including: http://www.secg.org/?action=docs_secg and OpenSSL, libecc, sks-ecc, and libcrypto++ have free implementations that might be worth perusing for reference or for comparison / test suites: http://openssl.org/ http://libecc.sourceforge.net/ http://sks.merseine.nu/ http://www.cryptopp.com/ It would be great to have a GPL-compatible, C implementation of ECC, and nettle seems like a good fit. Any thoughts, plans, or concerns about this? --dkg

4 7

Re: howto use openssl generated rsa keys with nettle
by nisse＠lysator.liu.se 05 Jan '11

05 Jan '11

Jyke Jokinen <jyke.jokinen(a)tut.fi> writes: > In private key the fields are (openssl rsa -in key.pem -text): > privateExponent: > prime1: > prime2: > exponent1: > exponent2: > coefficient: > > Prime1&2 should be the factors p and q in rsa_private_key(?) > What values should be used for a, b and c? If n = p q, e is the public exponent and d is the private exponent, then one should have a = d mod (p - 1) b = d mod (q - 1) c = q^{-1} (mod p) I've tried to explain this in rsa.h, suggestions for improving the documentation are welcome. I'm pretty sure openssl uses the same values. Off the top of my head I can't say for sure how to pair together nettle's names and openssl's, but I think they're in the same order, i.e., privateExponent = d prime1 = p prime2 = q exponent1 = a exponent2 = b coefficient = c Anyway, a, b, and c are redundant and can be computed from p, q and d, so you can check if the pairing above is correct. For converting keys in pkcs#1 format, also have a look at the program examples/pkcs1-conv.c, and the function rsa_keypair_from_der which it uses. Regards, /Niels PS. I've added your address to the non-member whitelist. I hope that works, and that you can now post to the list. (Default posting policy is members-only, as a desperate anti-spam measure). -- 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 13 Dec '10

13 Dec '10

Simon Josefsson <simon(a)josefsson.org> writes: > I was just curious whether you managed to get to the old code's speed > again. I did, and it now runs at about the same speed as with the old code. Actually, I don't think this exercise has introduced any interesting changes to the source code, it has just clarified that the current code is now a copy of the LGPL:ed code in libgcrypt (LGPL:ed) + some changes written by you and me. Anybody interested can try to diff the revisions before and after these sets of changes. 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 07 Dec '10

07 Dec '10

Simon Josefsson <simon(a)josefsson.org> writes: > What about the nettle.texinfo patch below? Sorry, forgot that. I've just checked in the following: @item BLOWFISH The implementation of the BLOWFISH cipher is written by Werner Koch, copyright owned by the Free Software Foundation. Also hacked by Simon Josefsson and Niels Möller. Released under the LGPL. > I'm not sure what changes Ray Dassen did, maybe those were part of the > old optimizations? Do they need to be re-licensed? No, those optimizations were done by me. I tried to look up the origin of the old code. Ray Dassen copied blowfish code from GNUPG to LSH, with a changelog entry dated Dec 12 1998 (see lsh/ChangeLog.1), the fourth oldest ChangeLog entry for lsh. The optimizations I reapplied were done by me, originally recorded in Nettle's ChangeLog 2001-06-17. > Btw, did you record what kind of performance you got with your > optimization applied? I would be surprised if you couldn't get close > to the same speed with simple changes. I'm not sure what you mean. The changes *are* simple. 2010-11-26 Niels Möller <nisse(a)lysator.liu.se> Reapplied optimizations (150% speedup on x86_32) and other fixes, relicensing them as LGPL. * blowfish.c (do_encrypt): Renamed, to... (encrypt): ...new name. (F): Added context argument. Shift input explicitly, instead of reading individual bytes via memory. (R): Added context argument. (encrypt): Deleted a bunch of local variables. Using the context pointer for everything should consume less registers. (decrypt): Likewise. (initial_ctx): Arrange constants into a struct, to simplify key setup. (blowfish_set_key): Some simplification. > I'll look at serpent next. Great! Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Jump to page:

2025

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