nettle-bugs

nettle-bugs@lists.lysator.liu.se

2196 discussions

developing nettle with git
by Daniel Kahn Gillmor 29 Mar '11

29 Mar '11

hi folks-- I'm managing my nettle work via git. I've extracted the cvs history of the upstream repo (nettle-only -- i'd rather not deal with all of lsh) and imported it into git. OF at all possible I plan to keep the "origin" branch up-to-date with the upstream CVS. Anyone who prefers to use git is welcome to use my repo as a jumping off point so you don't have to hassle with git cvsimport yourself. You can find it here: git clone git://lair.fifthhorseman.net/~dkg/nettle I would be happy to have nettle sources tracked as a separate project from lsh, just to make it easier for people to hack on it. Niels, if you want to consider transitioning nettle sources out of the the lsh repository and into something like git (or any other dvcs), i'd be happy to help you do that. Regards, --dkg

5 14

making algorithms in nettle dynamically enumerable
by Daniel Kahn Gillmor 23 Mar '11

23 Mar '11

Hi Nettle folks-- In the course of writing Crypt::Nettle, it occurs to me that i'm going to need to update the list of available ciphers and digests for each new version of nettle that comes out. This also means that newer versions of the perl bindings won't work by default against older versions of libnettle, which seems like it might make the perl bindings less useful for people who are stuck (for whatever reason) with an older version of libnettle. The attached patch would present an interface to dynamically enumerate the available ciphers and digest algorithms (and armor methods) supported by the current version of libnettle. bindings built against this meta-interface wouldn't need to be closely tied to any particular version of nettle, and so could be both forward- and backward-compatible. I'd be happy with any other interface that would give me the same effect, of course, and i'm not convinced that this is the best way to do it -- it just seemed the simplest in the current implementation. It would also be nice to make a similar interface to genericize cipher modes (ECB, CBC, CTR, and GCM), if that's possible; i'm not sure what the best approach is for doing that. Feedback welcome, of course. --dkg

3 12

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 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

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

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