On Tue, Dec 17, 2013 at 8:57 AM, Niels Möller wrote:
> I don't currently plan any 2.7.2 bugfix release. I'm thinking that this
> problem is not serious enough to motivate a new release. If some more
> urgent reason to make a release comes up, we can consider backporting
> this change.
> Or have yo
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 don't currently plan any 2.
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?
___
nettle-bugs mailin
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 wholesale gov
On Fri, Dec 13, 2013 at 11:33 AM, Niels Möller wrote:
> Nikos Mavrogiannopoulos writes:
>
>> What about the attached patch?
> Looks good! Some minor comments:
updated.
regards,
Nikos
From 87a82925c955024c1b20e45a810cc252170842c4 Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Fri,
Nikos Mavrogiannopoulos writes:
> What about the attached patch?
Looks good! Some minor comments:
--- /dev/null
+++ b/bignum-internal.h
> +inline static void* _tmp_gmp_alloc(unsigned* out_n, size_t n)
> +inline static void _tmp_gmp_free(void* p, size_t n)
I don't think the _tmp prefix is nee
On Thu, Dec 12, 2013 at 5:31 PM, Niels Möller wrote:
>>> That said, Nettle shouldn't do unbounded stack allocations in this case,
>>> it ought to use malloc, or abort or fail in some other *reliable*
>>> fashion. (I think having some documented limit on keysize would be
>>> acceptable, but I'm le
Nikos Mavrogiannopoulos writes:
>> That said, Nettle shouldn't do unbounded stack allocations in this case,
>> it ought to use malloc, or abort or fail in some other *reliable*
>> fashion. (I think having some documented limit on keysize would be
>> acceptable, but I'm leaning towards saying that
On Thu, Dec 12, 2013 at 3:40 PM, Niels Möller wrote:
> I'm not too concerned about DoS here. An application receiving an RSA
> key from an untrusted source should impose some reasonable limit on
> keysize before it is used. If I send you a public RSA key with n and e
> of 10 bits, and some si
Nikos Mavrogiannopoulos writes:
> A fix that could suit the master branch is attached. That adds the
> possibility to return an error if the maximum sizes are exceeded.
For the functions involving bignums, I wonder if it's better to allocate
the needed storage, either with malloc or with gmp all
On Wed, Dec 11, 2013 at 3:13 PM, Nikos Mavrogiannopoulos
wrote:
> As far as I understand that size assumption is only enforced on
> systems without alloca using an assert. In systems with alloca there
> is no such check. In both cases, it seems to be easy to abuse them for
> a denial of service.
On Wed, Dec 11, 2013 at 2:47 PM, Niels Möller wrote:
>> Ok didn't notice that. However, the bignum functions like
>> pkcs1_decrypt, pkcs1_encrypt, pkcs1_rsa_digest_encode,
>> nettle_mpz_random_size seem to have no such limits.
> They work under the assumption that key_size is less than 1 bits
Nikos Mavrogiannopoulos writes:
> Ok didn't notice that. However, the bignum functions like
> pkcs1_decrypt, pkcs1_encrypt, pkcs1_rsa_digest_encode,
> nettle_mpz_random_size seem to have no such limits.
They work under the assumption that key_size is less than 1 bits
(see NETTLE_MAX_BIGNUM_B
On Wed, Dec 11, 2013 at 12:56 PM, Niels Möller wrote:
> In ctr.c, the max size is 128 bytes (NBLOCKS *
> NETTLE_MAX_CIPHER_BLOCK_SIZE).
Ok didn't notice that. However, the bignum functions like
pkcs1_decrypt, pkcs1_encrypt, pkcs1_rsa_digest_encode,
nettle_mpz_random_size seem to have no such limi
Nikos Mavrogiannopoulos writes:
> In master (unsigned int) was replaced with (size_t), that allows for
> even larger sizes to be input to encryption and decryption functions.
> However, the usage of TMP_ALLOC to make a copy of the input data
> (e.g., in ctr.c) contradicts that goal.
The intenti
Hello,
In master (unsigned int) was replaced with (size_t), that allows for
even larger sizes to be input to encryption and decryption functions.
However, the usage of TMP_ALLOC to make a copy of the input data
(e.g., in ctr.c) contradicts that goal.
In general I think the usage of alloca() is da
16 matches
Mail list logo
