[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libnettle/libhogweed WIP
From: |
Eli Zaretskii |
Subject: |
Re: libnettle/libhogweed WIP |
Date: |
Fri, 21 Apr 2017 22:15:16 +0300 |
> From: Lars Ingebrigtsen <address@hidden>
> Date: Fri, 21 Apr 2017 20:45:58 +0200
>
> If I understand the code correctly (and I may definitely not be doing
> that; I've just skimmed it very, very briefly), you may be able to point
> the encryption code at the Emacs buffer contents directly without
> copying it anywhere beforehand, and then (since the results are usually
> of very similar length) back to the same Emacs buffer afterwards.
>
> 4GB Emacs buffer -> encrypted to 4GB GnuTLS buffer -> 4GB Emacs buffer
But since (AFAIU) the size of the encrypted text is not always known
in advance, the encryption might be significantly slower than just
reading in the original file, because of the need to enlarge the gap
(and thus reallocate text) several times. Similar things happen when
you visit a compressed file, which triggers its on-the-fly
decompression.
> (with-temp-buffer
> (set-buffer-multibyte nil) <<<<<<<<<<<<<<< this is not needed
> (let ((coding-system-for-read 'binary)
> (coding-system-for-write 'binary))
> (unwind-protect
> (progn
> (insert-file-contents "My DVD.iso")
> (gnutls-encrypt ... ... (current-buffer))
> (write-region ...))
> (clear-buffer (current-buffer))))) ;; New function that runs memset
> ;; over the buffer area
>
> Or something. We have to look at what buffers write-region creates and
> stuff, but in the 'binary case, I don't think it creates copies of the
> Emacs buffer anywhere.
The data will always leave traces, because doing the above involves
reallocation of memory, so you are likely to leave traces in the page
file and in memory. But I don't think you can avoid that, whatever
you do: as long as data needs to be read into memory to process it, it
will always leave traces.
- Re: libnettle/libhogweed WIP, (continued)
- Re: libnettle/libhogweed WIP, Noam Postavsky, 2017/04/18
- Re: libnettle/libhogweed WIP, Davis Herring, 2017/04/19
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/19
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/20
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/20
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/20
- Re: libnettle/libhogweed WIP, Lars Ingebrigtsen, 2017/04/20
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/20
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/21
- Re: libnettle/libhogweed WIP, Lars Ingebrigtsen, 2017/04/21
- Re: libnettle/libhogweed WIP,
Eli Zaretskii <=
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/21
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/18
- Re: libnettle/libhogweed WIP, Stefan Monnier, 2017/04/19
- Re: libnettle/libhogweed WIP, Lars Ingebrigtsen, 2017/04/19
- Re: libnettle/libhogweed WIP, Stefan Monnier, 2017/04/19
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/19
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/19
- Re: libnettle/libhogweed WIP, Stefan Monnier, 2017/04/19
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/19
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/19