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 …
[View More]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.
[View Less]
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 …
[View More]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
[View Less]
[ 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 …
[View More]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.
[View Less]
[ 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.
…
[View More]Internet email is subject to wholesale government surveillance.
[View Less]
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. …
[View More]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.
[View Less]