Hi Niels--
On Fri 2023-11-17 08:40:37 +0100, Niels Möller wrote:
> Hi, that's a bug, let me give some background.
thanks for the explanation, that matches roughly what i expected from
the comments in the source code. :)
> But then that test was was broken in a later fix to add more input
> valid
Hey Nettle folks--
I'm experimenting with using valgrind on the testsuite on the debian
platform. on x86_64, testing 3.9.1 as built on debian (debian package
version 3.9.1-2, built and run against libgmp10 debian package
2:6.3.0+dfsg-2), all valgrind tests succeed except for
rsa-sec-decrypt-test.
On Wed 2019-10-23 20:14:15 +0200, Niels Möller wrote:
> But nettle.html is generated with makeinfo and looks slightly different.
> The nettle.texinfo file includes
>
> @documentencoding UTF-8
>
> and the generated nettle.html carries a
>
>
>
> but it seems that isn't enough. Any clues appreci
Hi Niels--
i notice that https://www.lysator.liu.se/~nisse/nettle/nettle.html is
served with the HTTP header:
Content-Type: text/html; charset=iso-8859-1
but it contains non-ASCII text -- your name "Niels Möller", but it is
rendered as Niels Möller due to the charset parameter.
You can upda
On Thu 2017-05-18 10:43:26 +0300, Gabriel Ivașcu wrote:
> Dear Nettle developers,
>
> I see Nettle currently supports only some variations of PBKDF2 so I
> was wondering whether there could be added support for more KDFs [0].
>
> In my particular case it would be nice to have support for HKDF [1].
Hi Niels--
On Mon 2016-06-20 01:30:47 -0400, Niels Möller wrote:
> I'm considering the below patch, making use of the side-channel silent
> mpz_powm_sec function. The idea is to make the RSA and DSA code less
> vulnerable to side-channel attacks.
This is a good goal for Nettle to have. Thanks!
On Sat 2015-05-23 04:37:40 -0400, Niels Möller wrote:
> The issue is that there are some differences in generated nettle header
> files depending on architecture and compiler version.
If the differences are significant (e.g. if there are structs,
functions, or #defines that are declared differentl
On 12/12/2014 01:49 PM, ni...@lysator.liu.se (Niels Möller) wrote:
> Now, maybe we have to break the ABI
> for 3.1 anyway, to introduce versioned symbols. I don't yet know for
> sure if an soname change is necessary or not.
My experience is that tools built against a library with unversioned
symb
---
ecc-mod.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ecc-mod.c b/ecc-mod.c
index 7876d02..3301506 100644
--- a/ecc-mod.c
+++ b/ecc-mod.c
@@ -40,7 +40,7 @@
#include "ecc-internal.h"
/* Computes r mod m, where m is of size mn. bp holds B^mn mod m, as mn
- limbs, bu
On 06/20/2014 08:50 AM, Nikos Mavrogiannopoulos wrote:
> What do you think of having OCB mode in nettle? I particularly like
> OCB due to it's simplicity and performance comparing to GCM/CCM,
I'd love to see OCB made available in nettle for these exact reasons.
> What do you think? Should the
On 06/08/2014 12:43 PM, Niels Möller wrote:
> For public access, "git:" in the URLs must be replaced by "https:", like
>
> https://git.lysator.liu.se/nettle/nettle.git
tested, and this works fine for me. I did:
git config remote.origin.url \
https://git.lysator.liu.se/nettle/nettle.git
On 04/11/2014 01:49 PM, Niels Möller wrote:
> I'm considering removing the following features:
>
> * des-compat.h and all its functions. This provides some level of
> compatiblity with libdes (and possibly also old versions of
> openssl/ssleay). I've not heard of anyone actually using this.
hi nettle folks--
The list of language bindings at:
http://www.lysator.liu.se/~nisse/nettle/
doesn't mention haskell yet, but Clint Adams' nettle bindings for that
language are available here:
http://hackage.haskell.org/package/bindings-nettle
They're not exhaustive, but probably worth poi
On 12/06/2013 03:12 PM, Niels Möller wrote:
> I think the main point of the smaller group in DSA is to get small
> signatures.
>
> And discrete logs in the large group and discrete logs in the small
> subgroup are of comparable difficulty, because there's more structure in
> the larger group ("ind
On Fri 2013-12-06 15:12:57 -0500, Niels Möller wrote:
> I think the main point of the smaller group in DSA is to get small
> signatures.
>
> And discrete logs in the large group and discrete logs in the small
> subgroup are of comparable difficulty, because there's more structure in
> the larger gr
On 12/06/2013 02:00 PM, Niels Möller wrote:
> Simplest would be to just drop these requirements from
> dsa_generate_keypair, and let it do whatever the caller asks for. Do you
> think that makes sense?
This seems reasonable to me, even for people who want to make DSA keys.
If they want to follow
On 09/30/2013 08:46 AM, Nikos Mavrogiannopoulos wrote:
> There has been lately an attempt to avoid the NIST's curves due to
> suspicions about their generation. One of them are the brainpool curves
> at: http://tools.ietf.org/html/rfc5639
> which seem to be sponsored by the German BSI. Having them
On 03/12/2013 05:51 AM, Niels Möller wrote:
> In my benchmarks, AES decrypt is significantly slower than AES decrypt,
> for no reason that I understand, and I have tried some other variants of
> instruction scheduling.
You've got "AES decrypt" in both parts of the sentence above -- i assume
one o
On 11/27/2012 04:20 PM, Niels Möller wrote:
> Now we get to patching patches, which gets a bit messy, but I suspect it
> will work fine if you replace
>
> for (i = 0; i < _SALSA20_INPUT_LENGTH; i++)
> LE_WRITE_UINT32(&dst[i * sizeof (uint32_t)], dst32[i]);
>
> at the end of Simon's salsa20_
On 11/06/2012 12:27 PM, Niels Möller wrote:
> _salsa20_core produces byteswapped output (a somewhat peculiar
> interface, but it's an internal function, the reason is to be able do do
> any needed swap with word operations). So I think it should be a plain
> memcpy above.
>
> Testing on both littl
tle_cipher} nettle_arcfour128
commit 31f6181defb49d3ebf489376d3da45e30ea98333
Author: Daniel Kahn Gillmor
Date: Wed Aug 8 00:53:06 2012 -0400
fix GCM capitalization
diff --git a/nettle.texinfo b/nettle.texinfo
index cfb4c57..4904d91 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -1472
On 04/06/2012 08:39 AM, Nikos Mavrogiannopoulos wrote:
> Attached you'll find an initial patch that adds timing resistant
> versions of rsa_compute_root() and rsa_decrypt().
No patch was attached to the version of the message i received from the
list. Maybe try it again?
--dkg
signa
On 02/06/2012 01:42 PM, Simon Josefsson wrote:
> For most people, working on master and/or the latest stable release is
> what's interesting. So I'd say do a git conversion and then make a
> release from git and then work forward from there.
I'd agree with this. people who are providing longer-
On 01/31/2012 09:50 AM, Martin Storsjö wrote:
> On Tue, 31 Jan 2012, Niels Möller wrote:
>
>> Testing and general browsing of the history is appreciated. In a few
>> days, I think I'll consider the conversion final.
>
> The author mapping looks good to me at least, looking forward to the
> final
On 06/13/2011 08:02 AM, Niels Möller wrote:
> When one really wants repeatability, one can use the (otherwise pretty
> useless) lfib_knuth generator rather than yarrow256.
I've actually found that yarrow256 itself *is* repeatable across nettle
versions (well, 2.0 → 2.1 at least); it was just the R
Hi Nettle folks--
I'm wondering if there's an expectation of repeatable RSA key generation
across different versions of libnettle.
In particular, assuming a statically-seeded PRNG (e.g. seeding with a
fixed number of bytes from /dev/zero), should I be able to call
rsa_generate_keypair() and have
On 03/29/2011 03:38 PM, Niels Möller wrote:
> Daniel Kahn Gillmor writes:
>
>> this is quite a bit of code duplication across bindings.
>
> Could you be a bit more concrete? Which variant of wrappers and weak-key
> interface are you thinking about?
sorry -- i meant that it
On 03/29/2011 05:02 AM, Niels Möller wrote:
> If you're fine with either having weak keys always raise an exception or
> always be accepted, you could write set_key wrappers for the affected
> ciphers which do precisely that and which adhere to the
> nettle_set_key_func interface (note that des_set
hi nettle folks--
now that Crypt::Nettle seems effective and functional, i'm starting to
look at using it in other systems i'm working on. Suddenly, i realize
i'm missing access to 3DES and BLOWFISH, which i find i actually want :/
I'm missing them because there is no struct nettle_cipher for th
hi nettle folks--
the nettle docs say:
> In Nettle, most key setup functions have no return value, but
> for ciphers with weak keys, the return value indicates whether or not
> the given key is weak.
[...]
> A problem is that the key
> setup of ARCFOUR is quite weak, you should never use keys
On 03/28/2011 09:07 AM, Niels Möller wrote:
> Maybe it makes things simpler to stick to a single repository for
> everything (like the current cvs repository)? Is there any compelling
> reason why nettle must be a separate repository? (If I understand the
> docs correctly, one could split off a net
On 03/28/2011 04:15 AM, Niels Möller wrote:
> I take it I first need to scan the cvs log for all comitters and write a
> cvs-authors file (I remember I had some trouble with character set
> issues for the corresponding file when doing the hg migration for gmp.
> Should the names here be in the $LC_
On 03/28/2011 03:17 AM, Niels Möller wrote:
> Daniel Kahn Gillmor writes:
>
>> hm, are you talking about making binary releases? or source releases?
>
> I'm talking about the source releases of lsh.
I'm a software developer, a sysadmin, and a contributor to a distr
On 03/26/2011 03:46 AM, Niels Möller wrote:
> The main reason is that lsh is the main testcase. So when introducing
> new features one of those those libraries, I usually first hack lsh to
> use it, to iron out both interface and implementation bugs. Those
> intermediate versions may never be in th
On 03/25/2011 06:45 AM, Niels Möller wrote:
> 1. I'm familiar with mercurial, but I hear that git is a better choice
>these days, so maybe I should go with git instead. And then I have
>some new stuff to learn.
i find myself more effective with git than with mercurial, but i
acknowledge th
On 03/23/2011 06:12 AM, Niels Möller wrote:
> Thanks. I'm going to commit this. I noticed some incorrect file names in
> the file headers (which I'll fix), and there's no copyright line. I
> guess I should simply add
>
> Copyright (C) 2011 Daniel Kahn Gillmor
&g
On 03/23/2011 06:25 AM, Niels Möller wrote:
> Daniel Kahn Gillmor writes:
>
>> Any further comments?
>
> The following (in nettle.texinfo) looks a bit strange.
>
>> +@deftypevrx {Constant Struct * Constant} {struct nettle_hash *}
>> nettle_hashes[]
>
>
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 gi
On 03/21/2011 04:32 PM, Daniel Kahn Gillmor wrote:
> i'll work on a revised patch with docs and a test if i can figure out a
> test as well.
Attached is a patch that breaks out separate compilation units,
const-ifies the arrays, and adjusts the docs and the test suite.
I did not see n
On 03/21/2011 04:07 PM, Niels Möller wrote:
> But I think the API you suggested is good enough for now.
ok.
> The general principle is that independent functionality should be in
> separate object files. I don't think this case is an exception. To be a
> little more concrete, say you want a tool
On 03/21/2011 03:04 PM, Niels Möller wrote:
> I don't know how the build system for the perl bindings is setup, but
> using something like autoconf should make it easier if you really want
> to support multiple nettle versions, with or without public key support.
that's an interesting suggestion -
On 03/21/2011 09:41 AM, Niels Möller wrote:
> I agree this rejection was silly. I'm not so good at mailman
> configuration. The "pass_mime_types" option was set to
>
> text/plain
> multipart/signed
>
> I'm now changing it to
>
> text
> multipart
> application/pgp-signature
>
> Do you
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
On 03/21/2011 02:24 AM, Daniel Kahn Gillmor wrote:
> 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?
Gah, this question was already answered by niels several days ago,
though it was after i sen
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 se
On 03/18/2011 01:55 AM, Niels Möller wrote:
> Daniel Kahn Gillmor writes:
>
>> Niels, this is clearly a derivative work of Nettle. I'm happy to put
>> whatever free license you think is appropriate on it. Is GPL-2+ OK?
>
> If by "GPL-2+" you mean GPL
On 03/17/2011 05:50 AM, Daniel Kahn Gillmor wrote:
> I think getting RSA working is higher priority for me at the moment,
And now it's done -- I just wrapped up Crypt::Nettle::Yarrow and
Crypt::Nettle::RSA! I'm about ready to tag this thing as Crypt::Nettle
version 0.1. I'l
On 03/17/2011 05:29 AM, Niels Möller wrote:
> Daniel Kahn Gillmor writes:
>> My problem with this is that i then have to handle the case where the
>> user invokes process() without having remembered to set a key.
>
> Can't you just raise some error ?
Sure, but that i
Hi Simon--
On 03/17/2011 04:45 AM, Simon Josefsson wrote:
> Don't forget to add RSA blinding, otherwise it may be vulnerable in the
> real world. I wish Nettle supported this natively, RSA is not generally
> safe without it.
Thanks for this suggestion -- i'm not sure that the perl bindings are
t
rst place.
> : COPYRIGHT AND LICENSE
> : Copyright (c) Daniel Kahn Gillmor Crypt::Nettle is free software, you
> : may redistribute it and/or modify it under the same terms as Perl
> : itself.
>
> The GPL/LGPL license of the nettle library itself may apply to perl
&
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 avail
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 shar
On 02/11/2011 05:39 AM, Nikos Mavrogiannopoulos wrote:
> I'am just repeating myself and might become annoying... but does it
> really worth the time? Is there anyone using that algorithm, or anyone
> planning to use it? As it stands now serpent is an academic cipher,
> it is not used in any protoco
53 matches
Mail list logo
