gt; - return 1;
> + ret = 1;
> +err:
> + TMP_GMP_FREE(em);
> + return ret;
> }
"err" is maybe not the right name for the label, since the code is also
for successful termination. "done" or "cleanup" would be better.
Regards,
/Niels
--
Niels Mö
and refers to
http://www.lysator.liu.se/~nisse/nettle/ for instructions. That page
says "After checkout, you need to run the .bootstrap script before the
standard ./configure && make.". Maybe that could be made clearer in some
way?
Regards,
/Niels
--
Niels Möller. PGP-encrypted ema
trying to build with modern gcc and binutils,
before trying to find workarounds for apple's tools.
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
__
macro in
config.m4.
> As said before, all previous releases of nettle
> have worked just fine on OS X.
That's very nice, and in a large part that's thanks to your work.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Inte
Martin Storsjö writes:
> Your C code snippet seemed to use .short
Ok, I've now changed gcm-hash8.asm to also use .short.
Remains the configure test for rodata. Not sure what's best, but perhaps
easiest to just check of $host_os is darwin.
Regards,
/Niels
--
Niels Möller. PGP-en
Nikos Mavrogiannopoulos writes:
> updated.
Checked in now, with minor changes (deleted the out_n argument for
gmp_alloc, and moved the TMP_GMP_* macros to gmp-glue.h).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholes
.Lshift_table:
.short W(00,00),W(01,c2),W(03,84),W(02,46),W(07,08),W(06,ca),W(04,8c),W(05,4e)
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs maili
Nikos Mavrogiannopoulos writes:
> On Sun, 2013-12-15 at 19:19 +0100, Niels Möller wrote:
>
>> Checked in now, with minor changes (deleted the out_n argument for
>> gmp_alloc, and moved the TMP_GMP_* macros to gmp-glue.h).
>
> Would that be included in a 2.7 release?
I
sts for that as too? To me, it seems a bit
unlikely to need a fat binary which supports both pre-v6 arm, and v6 and
later. I'd expect pre-v6 arm to be used only in embedded systems where
the cpu flavor is known at build time.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferre
this.
>> I clearly see the need for a runtime test for neon. Say,
>> --enable-arm-neon=fat or a more general --enable-fat.
>
> I like the name :) I think the latter makes more sense if it is to be used
> for x86 as well.
--enable-fat is what gmp uses. And "fat binarie
Martin Storsjö writes:
> On Tue, 17 Dec 2013, Niels Möller wrote:
>
>> There's also IFUNC relocations, but I'm not sure which systems beyond
>> vanilla gnu/linux support them. Are they usable on android, e.g.?
>
> Not sure - and even if they are they might
ni...@lysator.liu.se (Niels Möller) writes:
> Below is an untested patch for the configure machinery. Can you try this?
I haven't seen any feedback on this, but I have now checked it in
nonetheless.
It would be nice if you could confirm that it actually works. If you or
Martin also hav
Joachim Strömbergson writes:
> At least not having one indirection in documentation. I think the
> bootstrap should be mentioned directly in a README, INSTALL etc file
> directly in the reop.
I did some small changes to the README, to try to make it clearer.
Regards,
/Niels
--
Nie
ni...@lysator.liu.se (Niels Möller) writes:
> Two reasons: 1. To make the fat binary thing optional, just using a
> simple cpu-specific file when the cpu is known at compile time. 2. In
> case we'd like to fallback to the C implementation for some function.
I checked what function
, that will cause for real android devices.
But it seems fairly common that android apps are compiled for newer
processors only (if they include native code at all), e.g., I think the
firefox app I got from f-droid is armv7 only.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred
ion algorithm. Not entirely trivial to do with the mpz interface,
though.
On mitigation, it also sounds like RSA blinding (which you implemented a
while ago) is effective. It ought to be effective against any attacks
relying on *chosen* ciphertexts.
(And I think you forgot to attach the patch).
ings/errors with valgrind?
The memxor-test.c in the repo tries to run memxor and memxor3 with all
combinations of alignments and a selection of different sizes. And I get
no warnings from
make check EMULATOR='$(VALGRIND)' TS_ALL=memxor-test
As far as I see, those tests *should* in
.
> In the memxor tests, do you put the buffers at a zone exactly at the
> ending position of the buffer,
No. That's probably why valgrind doesn't warn about it. I just allocate
a buffer of 16 + MAX_SIZE bytes, and try with starting address buf,
buf+1, ..., buf + 15.
Regards,
/Niel
ould require local patches to be provided. I can send
> out the patches to you.
I can get config.guess from the above git repo. I guess it's the
"timestamp='2013-11-29'" version you used?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B
Nettle's public key support is completely disabled).
What do you think?
Relatedly, I've updated the release plan on
http://www.lysator.liu.se/~nisse/nettle/plan.html.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subj
rray in struct sha256_ctx. And a separate define for sha224
makes little sense, because there is no separate struct sha224_ctx, it's
just a #define alias for sha256_ctx.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject
are simple patterns.
I've added comments for sha1 and sha224.
> According to Thomas the sequence pattern in md5 was choosen by Rivest
> quite arbitrarily.
Not much to comment there...
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid
the darwin testing on OSX 10.9.x
Good!
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
indings-nettle
Cool. Added to the list now.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
h
e considered broken.", but those
standards clearly don't apply to assembly code).
3. memxor.c might also use "partial loads" in a way which violates C
standards. I don't think that's a problem on any real system, and,
e.g, glibc memcmp does similar tricks.
R
EAD
I have now updated nettle's copies of config.guess and config.sub to the
latest versions (both timestamped 2014-01-01).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale gov
/Makefile.in. I usually run valgrind with the invocation
make check EMULATOR='$(VALGRIND)'
Without that flag, I get tons of warnings for both x86_64/memxor.asm and
memxor.c.
It would make sense to add similar client requests to more testcases.
Regards,
/Niels
--
Niels Möller. PGP-enc
ode
depending on endianness (and WORDS_BIGENDIAN), which strictly speaking
is not valid C. But I don't intend to fix such things unless it breaks
things on some otherwise supported platform.
If needed, we can add a configure test and a simple and 100% kosher
byte-by-byte memxor loop for affected
Just let the test programs use
VALGRIND_MAKE_MEM_UNDEFINED to mark the areas with secret data, which
memory accesses and branches ought to not depend on.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale govern
0x63, 0x1f, 0xed, 0xd8, 0x8e, 0x8b, 0xfb, 0x84,
+ 0xad, 0x6b, 0x21, 0x3b, 0xde, 0xe4, 0xbc, 0x80,
+ 0x6e, 0x27, 0x64, 0x93, 0x5f, 0xb8, 0x90, 0x97,
+ 0x21, 0x8a, 0x89, 0x7b, 0x7a, 0xea, 0xd1, 0x0
liu.se/~nisse/nettle/? If
so, please suggest wording. I'm not familiar with Haskell.
> it should ensure that you can't screw up memory allocation and
> so on, because otherwise I don't see a reason not to use C in the first
> place :)
Makes a lot of sense to me.
Regards,
ni...@lysator.liu.se (Niels Möller) writes:
> Should this be listed on http://www.lysator.liu.se/~nisse/nettle/?
And looking at this list, I just noticed that the link to the scheme
bindings, http://marcomaggi.github.com/nausicaa.html, is dead. Anyone
knows what happened?
Regards,
/Ni
ni...@lysator.liu.se (Niels Möller) writes:
> I edited it a bit, to take out support for rounds != 20 for now (except
> for the _chacha_core_internal function), and I split the set key
> function into two functions for the two available key sizes, 128 and 256
> bits.
I have a couple
think they should have a
different name space (e.g., xsalsa*), so at least they shouldn't collide
with plain salsa20 functions.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
{
default: abort ();
case 16:
chacha128_set_key(...);
break;
case 32:
chacha256_set_key(...);
break;
}
}
Maybe that's clutter, but I think the actual complexity cost is pretty
low, so I don't think we have to be very afraid of it.
Regards,
/Niels
--
ni...@lysator.liu.se (Niels Möller) writes:
> I expect that every byte of memory which is accessible at all is
> accessible using an aligned read access of a full word. I view
> byte-sized loads in the instruction set as mostly syntactic sugar for
> word-sized loads and masking.
Afte
-nostartfiles?
We currently pass -G on solaris, -dynamiclib on darwin/macos, and
-shared everywhere else. I'd expect those flags to imply -nostartfiles,
but I don't really know how that works.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Interne
ill be
void
salsa20_128_set_key(struct salsa20_ctx *ctx, const uint8_t *key);
void
salsa20_256_set_key(struct salsa20_ctx *ctx, const uint8_t *key);
void
salsa20_set_key(struct salsa20_ctx *ctx,
size_t length, const uint8_t *key);
then.
Regards,
/Niels
--
Niels Möller. PGP-encrypt
hods to provide authentication but no
encryption, like hmac-sha256 or poly1305. But I doubt that's very
useful.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
ni...@lysator.liu.se (Niels Möller) writes:
> Joachim Strömbergson writes:
>
>> What is the status of Poly1305 in Nettle, i.e. is the branch ready to be
>> merged into master
>
> There are a couple of things I'd like to do. Quoting a mail from 21/11:
I've done
ng something? I guess Adam Langley usually knows what he's
doing. But otherwise, the paragraph in the draft, and the awkward method
it describes, makes absolutely no sense to me.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is sub
in NaCl".
Ok, I have to look that up, probably that will make everything clear.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
ni...@lysator.liu.se (Niels Möller) writes:
>> Camellia uses fewer subkeys for 128 bit keys than for 192 or 256 bit
>> keys. So this is a bit similar to AES, and I think an analogous reorg
>> would make sense.
>
> I tried this out now. New header file below.
Now mer
ni...@lysator.liu.se (Niels Möller) writes:
>> * Introduce a poly1305_update function, and use preprocessor casting
>> tricks to define poly1305_aes128_update (and any other
>> poly1305_*_update) as an alias.
>
> Done, then undone;
I tried the same trick for a di
ni...@lysator.liu.se (Niels Möller) writes:
> Resulting patch below. I think I'll check this in soon. Next steps would
> be:
>
> 1. Add it to the benchmark (probably easiest to do it the same way as
>salsa20, with a struct in nettle-internal.c).
>
> 2. Adapt
able benefit). So if this
works out well for chacha, the same could be done for salsa20.
Ah, and chacha seems to be about 15% faster than salsa20
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale gov
irect
* use by Nettle by Simon Josefsson and Niels Möller.
*
* The implementation here is based on Peter Gutmann's RRC.2 paper and
* RFC 2268.
*/
Does anyone here know what applications or protocols use arctwo, and
with which key sizes?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email
Nikos Mavrogiannopoulos writes:
> However, RC2-40 is used in gnutls to decrypt PKCS #12 files, so it
> would be good for RC2-40 to remain so that decryption of any existing
> files will remain possible.
Ok, I leave that in, then.
Regards,
/Niels
--
Niels Möller. PGP-encrypted
key of fixed size 128 bits (16
bytes), and then I named the variable key size function "cast5_set_key".
It just seemed a bit too awkward to name the fix-sized function
cast128_128_set_key. If we ever add a specific set_key function for,
e.g., 80-bit cast5/cast128, I think that could b
arked the
code (I haven't been very systematic), pshufhw + pshuflw seems to be
slightly faster. It saves one por instruction.
I'm pretty sure doing a couple of blocks at a time in parellel,
interleaving the instructions, will give some speedup.
Regards,
/Niels
--
Niels Möller. PGP-encrypte
should also have a small redzone around
the destination area, to check for overwrites.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs
ore secure.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.
And about the "safe" curves listed at http://safecurves.cr.yp.to/,
anything beyond curve25519 which is being deployed? M-383, Curve41417,
M-511 or E-521?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet e
(or any
other related standard), though.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysato
ni...@lysator.liu.se (Niels Möller) writes:
> I've done this change. I didn't dare push it to the master branch just
> yet, so it's on a new branch "set_key-changes". The more interesting
> pieces of the ChangeLog below.
>
> Anyone who'd like to comm
ni...@lysator.liu.se (Niels Möller) writes:
> Next, AEAD (authenticated encryption with associated data).
Some questions on a general abstraction for this, and my tentative answers:
Q: Should it expose the block size?
A: Yes. The caller must pass data in chunks which are an integral num
ni...@lysator.liu.se (Niels Möller) writes:
> Testing could be improved, quoting the comments in chacha-test.c:
>
> /* FIXME: For rounds == 20, use crypt function, support more than
> one block, and test various short lengths. */
Done now. And I found and fixed one bug in
I'm continuing to reply to myself... It's the recurring question on
fixed size versus varying size of certain inputs and outputs.
ni...@lysator.liu.se (Niels Möller) writes:
> Q: Should the nonce size be fixed?
>
> A: Yes. Motivation: For a given key, fixed nonce size is good
Joachim Strömbergson writes:
> Niels Möller wrote:
>> Done now. And I found and fixed one bug in chacha_crypt. When
>> updating the block counter, it used the salsa20 state layout, not the
>> chacha state layout.
>
> Looking through the commits and docs... Holy cr-p
Thanks for the review.
Nikos Mavrogiannopoulos writes:
>On Fri, Feb 7, 2014 at 1:01 PM, Niels Möller wrote:
>> Q: Should it expose the block size?
> I'd say no because the whole purpose of AEAD (or at least my
> understanding of rfc5116) is to simplify the process of e
Stefan Bühler writes:
> Stripping attachments on the ml... really?
Last time I looked at this in the mailman config, I was too confused to
solve the problem. Maybe I should try again.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subj
ch case I'll delete my
> feature branch).
It would make sense to att at least a few of those to nettle's
testsuite/chacha-test.c. Thanks for the pointer!
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject t
tion should arrange to pass a large enough buffer, call the
encrypt/decrypt function, which returns the amount of output actually
produced.
Or use struct nettle_buffer for the destination operand, possibly in
combination with some macro/function to query the needed space.
Regards,
/Niels
--
N
ni...@lysator.liu.se (Niels Möller) writes:
> Q: Should the nonce size be fixed?
>
> A: Yes. Motivation: For a given key, fixed nonce size is good enough for
>RFC 5116. It's unclear if there are use-cases for varying the nonce size,
>and if needed one can define
it now, we could of course reintroduce it
later if it turns out to be needed).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
orithms may need to know the length of the plain text in
> advance (CCM for example).
I'm not really familiar with ccm, I've only read the critique of it in
the eax paper. But that sounds like it's killing streaming operations.
Regards,
/Niels
--
Niels M
ni...@lysator.liu.se (Niels Möller) writes:
> Or use struct nettle_buffer for the destination operand, possibly in
> combination with some macro/function to query the needed space.
I have now tried this approach. For those have haven't used
nettle_buffer, it's struct wit
I was pointed to
https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-01. This
draft specifies chacha as using a 96-bit nonce and a 32-bit block
counter. When asking about this discrepancy on the tls list, Adam
Langley replied
: On Fri, Feb 14, 2014 at 1:57 PM, Niels Möller wrote
or the
reminder.
Do you need all of gcm-camellia128, gcm-camellia192, gcm-camellia256, or
only some? (Your test program seems to only test the 128-bit variant,
but you also attacked a file with test data for the other sizes).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred.
e soon.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/m
ni...@lysator.liu.se (Niels Möller) writes:
> Need to prepare additional testcases (based on camellia_gcm_tv.txt)
> before adding the 256-bit variant. I hope I can get that done soon.
Done now. Nikos: From where did you get camellia_gcm_tv.txt? It would be
good to document the source
ni...@lysator.liu.se (Niels Möller) writes:
> There is some possibilty to let the two views of these input block
> coexist, but I'm afraid that will get a bit messy to support in Nettle
> (although I haven't yet thought very much about the details).
This is all about initializ
ni...@lysator.liu.se (Niels Möller) writes:
> Does anyone else know of use or interest in 128-bit chacha keys? It
> would definitely make things a bit simpler if we can omit support for
> 128-bit keys. (And if we skip it now, we could of course reintroduce it
> later if it turns out
Owen Kirby is working on an implementation of the CCM mode. I'm
forwarding my comments here (with permission).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveil
ni...@lysator.liu.se (Niels Möller) writes:
> Owen Kirby is working on an implementation of the CCM mode. I'm
> forwarding my comments here (with permission).
Ooops, I got bitten by the bad mailman configuration regarding
attachments. New attempt below. /Niels
Owen Kirby writes:
ni...@lysator.liu.se (Niels Möller) writes:
> Owen Kirby writes:
>> --- /dev/null
>> +++ b/ccm.h
>> +/* Obnoxiously, CCM mode requires the adata and message lengths when
>> + * building the IV. This prevents any sort of streaming type API to
>> + * the cipher
ni...@lysator.liu.se (Niels Möller) writes:
> Nikos Mavrogiannopoulos writes:
>
>> In the master branch you break the ABI anyway, so it may be a good time
>> to introduce that. Otherwise you may simply introduce new functions for
>> the new structures and leave the old A
ni...@lysator.liu.se (Niels Möller) writes:
> ni...@lysator.liu.se (Niels Möller) writes:
>
>> Nikos Mavrogiannopoulos writes:
>>
>>> In the master branch you break the ABI anyway, so it may be a good time
>>> to introduce that. Otherwise you may simply int
Daniel Kahn Gillmor writes:
> On Fri 2013-12-06 15:12:57 -0500, Niels Möller wrote:
>
>> For DH, I don't think there's any particular reason to prefer to work in
>> a small subgroup. But I may be missing something, of course.
>
> I can think of a few, but i&
ni...@lysator.liu.se (Niels Möller) writes:
> One possibility might be to have all dsa functions take the dsa group
> parameters and the actual key as separate function arguments.
I've tried this now. I think it looks reasonably good. Excerpts from the
new dsa.h:
struct
LGPLv2 or later) to a dual license, LGPLv3 or later, or GPLv2 or later.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing l
.h (libdes-compatible
interface)?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.
/
> + if (repeat <= 1) {
> +memset(en_data, 0, len); memset(de_data, 0, len);
> +memset(en_digest, 0, tlen); memset(de_digest, 0, tlen);
> +
> +ccm_encrypt_message(ctx, cipher->encrypt, nonce->length, nonce->data,
> +authdata->length, au
then drop the alength
argument from set_nonce. And I think allowing multiple calls to
ccm_update seems desirable, so I'd prefer the first option. Do you
agree?
> On Sat, Mar 15, 2014 at 12:07 AM, Niels Möller wrote:
>> Is it possible to move this initial processing to ccm_set_nonce
ni...@lysator.liu.se (Niels Möller) writes:
> * Complete the dsa reorg (I'd appreciate all comments on that).
Not much comments on these issues. I'm now leaning towards a split into
dsa.h with the new interface (and unchanged pieces, like struct
dsa_signature), and a dsa-compat.h,
nd not bother with any additional aliases for context struct and
_update function). Is that ok?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
net
that function, if that makes
application code prettier.
Minor nit: I prefer patches in unified format.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
__
c source
file anyway, maybe these objects could be placed together in
sha384-meta.c. With this in place, adding them to
examples/nettle-benchmark.c is trivial.
Should also update nettle-meta-hashes.c and correspnding test case.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is
in separate files.
> I'll do some hacking on this and the docs.
I look forward to that. Of the missing things, test cases are most
important, I think.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government su
are
replaced by nettle_cipher_func (introduced last week), and the cipher
context arguments accordingly changed to const. And some tweaks of
indentation and line breaks.
Documentation remains to do.
Thanks,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet emai
ni...@lysator.liu.se (Niels Möller) writes:
> I really not sure about the best way to go about it. Another option
> might be to purge all deprecated stuff from dsa.h, and put it into a new
> file dsa-compat.h.
I've now done this, and pushed it on the dsa-reorg branch. I also
ni...@lysator.liu.se (Niels Möller) writes:
> Unless there are objections, I think I'm going to merge this to the
> master branch as soon as I get the time. (Most likely a manual merge, to
> avoid checking in dead ends). We really need to get this over with.
Pushed now.
R
gmp and mini-gmp functions.
For the nettle testsuite, I hope one can get by with something simpler.
Do as many of the tests as possible using mini-gmp only, and disable
tests which depend on functions only available in the real gmp library,
e.g., mpz_urandomb.
Regards,
/Niels
--
Niels Möller. PG
Nikos Mavrogiannopoulos writes:
> This patch allows comparing the performance differences in secp256r1
> (the curve mostly used in the web), between nettle and openssl.
Thanks, pushed now.
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subj
ni...@lysator.liu.se (Niels Möller) writes:
> Pushed now, with some smaller changes.
I get a couple of warnings, when compiling for 32-bit platforms, e.g.,
ARM.
/home/nisse/hack/nettle/ccm.c: In function `nettle_ccm_set_nonce':
/home/nisse/hack/nettle/ccm.c:134:3: warning: comparison i
32-bits.
> I have some ARM boards that I can cross compile for, so
> I'll take a look at cleaning up the warnings when I get some time this
> weekend.
I think you get the same warnings if you configure with CC='gcc -m32'
CXX='g++ -m32' on a plain x86_64 gnu/linux box
se of these features, please speak
up.
(In case a feature is removed and it later turns out to be a mistake,
I'm open to reintroduce features in an update, but I believe there's
little need to keep these around).
And any other cruft which should be removed while we're at it?
Regar
Daniel Kahn Gillmor writes:
> 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 o
er should
select the nonce size. I'd expect that 12 bytes nonce (and the corresponding
limit on
message size) is the most widely used, following RFC 5116.
What happens if the caller specifies an invalid combination of nonce
size and message size? Will it trigger some assert, or will the counter
wrap
nce size is in the range 7...14 bytes,
inclusive.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.l
201 - 300 of 1429 matches
Mail list logo
