On 4/12/23 09:05, Niels Möller wrote:
Simo Sorce writes:
Ah you do not need to pass any property for the default provider so you
can pass "" or even NULL.
Thanks, I now have the RSA code updated (on branch update-openssl-bench,
if anyone wants to see the details). Initialization is now
ct
) function relevant to the
alphabet it is needing to encode/decode with. The library internally
uses the context to select which lookup table to use for later base64
function calls.
The base64_encode_raw() and base64_encode_group() functions which do
not use contexts are left untouched for now.
Amo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/01/2015 11:34 p.m., Nikos Mavrogiannopoulos wrote:
> On Tue, Jan 13, 2015 at 11:20 AM, Niels Möller wrote:
>> (Niels Möller) writes:
>>> Clearly, this will be more useful after adding support for fat
>>> binaries, detecting presence of these inst
On 13/12/2014 7:49 a.m., Niels Möller wrote:
> Amos Jeffries writes:
>
>> The attached patch implements a proposed API/ABI extension adding
>> support for RFC 4648 section 5 "Base 64 Encoding with URL and Filename
>> Safe Alphabet"
>
> Thanks. It makes se
On 29/01/2015 9:35 a.m., Niels Möller wrote:
> Looking at http://www.lysator.liu.se/~nisse/nettle/plan.html, the most
> important things are done. I think documentation is the only item left
> which is both important and requires several hours of work.
>
> * Base64 with other alphabets. A patch w
memset() a context to empty and provide the alphabet lookup table pointer.
Amos Jeffries
Treehouse Networks Ltd.
PS, I have also removed the dead code wrappend in "#if 0" rather than
updating it.
diff --git a/Makefile.in b/Makefile.in
index 2a940f9..48cce47 100644
--- a/Makefile.in
+++ b/
On 29/01/2015 5:51 p.m., Amos Jeffries wrote:
> RFC 4648 (https://tools.ietf.org/html/rfc4648) standardizes two
> Base-64 alphabets. Nettle currently only supports the traditional
> base-64 alphabet from section 4.
>
> There is growing use amongst new protocol definitions
On 29/01/2015 9:08 p.m., Niels Möller wrote:
> Amos Jeffries writes:
>
>> The attached patch implements a proposed API/ABI extension adding
>> support for RFC 4648 section 5 "Base 64 Encoding with URL and Filename
>> Safe Alphabet"
>
> Thanks. I have
On 30/01/2015 1:27 a.m., Niels Möller wrote:
> Amos Jeffries writes:
>
>> I have added a fuzz tester that runs a set of randomly generated strings
>> past the default encoder and decoder, then the extended one.
>
> Nice. It would be good with a couple of short manual ex
memset() a context to empty and provide the alphabet lookup table pointer.
Addtionally this patch adds a simple fuzz unit test for both Base-64 and
Base-64 URL extended alphabet encoders and decoders.
Amos Jeffries
Treehouse Networks Ltd.
PS, I have also removed the dead code wrappend in "#if
On 11/02/2015 10:24 a.m., Niels Möller wrote:
> Amos Jeffries writes:
>
>> The attached patch implements a proposed API/ABI extension adding
>> support for RFC 4648 section 5 "Base 64 Encoding with URL and Filename
>> Safe Alphabet"
>
> Committed now, with
On 14/03/2015 8:20 p.m., Niels Möller wrote:
> I think there's only one sensitive use of memcmp within nettle, and
> that's the tag comparison in ccm_decrypt_message. I've now written a
> private function memeql_sec to do that comparison in a more side-channel
> silent fashion.
>
> static int
>
On 15/03/2015 12:39 a.m., Niels Möller wrote:
> Amos Jeffries writes:
>
>> Is the compiler optimized code for that for loop faster or slower than a
>> loop suming the differentials?
>
> Not sure. But I don't think performance is very important here, the
> functi
On 1/04/2015 6:35 a.m., Niels Möller wrote:
> ni...@lysator.liu.se (Niels Möller) writes:
>
>> I've made an rc2 tarball, fixing known issues, except for the w64
>> problems which I haven't had time to debug yet.
>
> I think I have found the w64 problem. It breaks with mini-gmp.
>
> The problem i
On 2/05/2015 8:47 p.m., Niels Möller wrote:
> Now we see some transition problems,
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784009, and it's going
> to also hit other distributions than debian.
>
> Would it make sense to issue a nettle-2.7.2, which is nettle-2.7.1 +
> symbol versions? T
On 17/07/2016 10:14 p.m., Niels Möller wrote:
> I'd like to eliminate pointer-signedness warnings. I'm afraid some ugly
> casts will have to be involved, since most functions work with uint8_t,
> and at least test code needs to pass literal strings, of type char *.
>
> I have one question, on the
On 17/02/18 22:59, Jeffrey Walton wrote:
> On Sat, Feb 17, 2018 at 4:35 AM, Niels Möller wrote:
>> ...
>>> @@ -80,7 +80,7 @@ openssl_evp_set_encrypt_key(void *p, const uint8_t *key,
>>> {
>>>struct openssl_cipher_ctx *ctx = p;
>>>ctx->evp = EVP_CIPHER_CTX_new();
>>> - assert(EVP_EncryptIn
On 18/02/18 00:48, Nikos Mavrogiannopoulos wrote:
>
>
> On February 17, 2018 9:35:34 AM UTC, nisse wrote:
>> Dmitry Eremin-Solenikov writes:
>>
>>> For benchmarking purposes provide wrappers around OpenSSL AES GCM
>>> implementation. Note, digest callback will work only for encryption
>> due
>>>
On 13/03/18 07:40, Niels Möller wrote:
> nisse (Niels Möller) writes:
>
>> nisse (Niels Möller) writes:
>>
>>> I've been trying out the sha_ni instructions available on some newer
>>> x86_64 processors.
>>
>> And now that the gcc67 machine is up again, I got my sha256
>> implementation working too
On 13/03/18 08:44, Jeffrey Walton wrote:
> Check /proc/cpuinfo for the sha_ni flag. If present, then you can test
> the SHA extensions.
>
> SHA extensions made their debut in Goldmont. They are also available
> in Goldmont+. They were scheduled for one of the lakes but they did
> not make it in.
>
On 3/02/20 6:41 pm, Jeffrey Walton wrote:
> On Mon, Feb 3, 2020 at 12:26 AM Niels Möller wrote:
>>
>> Jeffrey Walton writes:
>>
>>> On Sun, Feb 2, 2020 at 11:48 PM Niels Möller wrote:
I don't have any time to spend on testing with these systems or
compilers. Do you think it makes sen
On 6/04/20 12:57 pm, Stephen R. van den Berg wrote:
> On Sun, Apr 5, 2020 at 7:57 PM Niels Möller wrote:
>
>> I'm not entirely sure halving the table size is a good tradeoff. If we
>> want to do it, that should be a separete change.
>
>
> You mean because it will cost an extra clockcycle on deco
On 22/05/20 11:29 pm, Emil Velikov wrote:
> On Mon, 11 May 2020 at 09:46, Emil Velikov wrote:
>>
>> The direct $HASH_{Init,Update,Final} has been discouraged for a while.
>> With the upcoming OpenSSL 3.0 it will be officially deprecated.
>>
>> Add a handy macro, to avoid repetition and mistakes lik
On 28/09/20 8:25 am, Maamoun TK wrote:
> gcm_fill() got C optimization which performs close to the one I
What do you mean by "close"?
faster or slower?
and it that difference consistent?
If the other implementation is slower (even by a few nanosec) it can be
useful keeping this fast code ar
On 19/12/20 5:29 am, Niels Möller wrote:
Andreas Metzler writes:
it would not count as transition
https://release.debian.org/bullseye/freeze_policy.html#transition
...
* Support for bcrypt, contributed by Stephen R. van den Berg.
I would have though this needs a soname bump. O
On 23/02/22 13:28, Maamoun TK wrote:
Benchmark the implementations on POWER9 and Z15
*-*
|Arch | Nettle patch (radix 2^44)| OpenSSL (radix
2^26) |
|---|
On 7/08/22 01:17, Niels Möller wrote:
Hi,
I'm considering deleting some assembly files for older architectures and
older algorithms. They will still be supported via the corresponding C
implementations, just (likely) slower. Why do that? I see two reasons:
1. Delete code that it's no longer eas
27 matches
Mail list logo
