emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libnettle/libhogweed WIP


From: Ted Zlatanov
Subject: Re: libnettle/libhogweed WIP
Date: Fri, 14 Apr 2017 16:48:39 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

On Tue, 11 Apr 2017 16:05:16 -0400 Ted Zlatanov <address@hidden> wrote: 

TZ> I updated the branch scratch/tzz/nettle with comprehensive
TZ> tests. It now mirrors the low-level API in the GnuTLS crypto.h
TZ> functions, so there's no libnettle/libhogweed dependency. The API was
TZ> pretty different so I had to rewrite almost everything.

I've put this work up on
https://gitlab.com/emacs-ci/emacs/merge_requests/2 for those who want to
use Gitlab to comment.

Updates from my previous post:

TZ> * the AEAD ciphers "CHACHA20-POLY1305" "AES-128-CCM-8" "AES-256-CCM-8"
TZ>   are not working yet.

This is fixed, all ciphers (AEAD and non-AEAD) work now.

TZ> * TODO from Eli: avoid allocating a scratch buffer and then copying its
TZ>   data (inside make_unibyte_string) into a newly-allocated string.
TZ>   Instead, use make_uninit_string.

I've done this as much as possible. For AEAD output, I'm not sure how to
set the length of an already-allocated string; I didn't want to modify
`s.size' directly. I didn't see a function or macro to do it. This is
needed for gnutls_symmetric_aead().

I also wanted to mention two possible avenues to explore:

1) how about a special C data structure that has to be called to get its
payload data, but can't be inspected or printed otherwise, and after N
reads is inaccessible? Would that be resistant to Lisp-level attempts to
grab the data?

2) Could there be a built-in C way to let C core functions take strings,
but callers can invoke them with '(buffer-string) to tell *the core
function* to call that form. In other words, I want the eval to be done
at the C level, so that looking at the call tree won't reveal the actual
string that was passed to the function. I think that would simplify my
code and other C code too. I can probably fake it with eval()? WDYT?

If that's not possible, I'll pull the first part of fns.c:secure_hash()
out into a common function for the gnutls.c crypto functions as well, so
they can take buffer contents etc. easily.

Ted




reply via email to

[Prev in Thread] Current Thread [Next in Thread]