harden crypto keys handling

[ThomasWaldmann]

Split off from #2525:

• Do not keep cryptographic keys around in Python objects

• Use secure memory for cryptographic keys

  This is offered by e.g. sodium_malloc. It works by aligning the data to the end of a page and mprotect()ing the following page with PROT_NONE. The remainder of the first page is filled with canary data. Finally another guard page is placed before the page containing the data. All three pages are mlock()d as well, to avoid swapping. Inclusion in core dumps is prohibited as well (MADV_DONTDUMP).

  Freeing memory checks the canaries and securely erases the contained data.

[ThomasWaldmann]

I suspect this has the same issue as #6478. The problem is not only "not to keep keys in python objects" and "using secure memory for keys", but also that for this being effective, encrypted borg key, passphrase, decrypted key material must never ever get into python objects.

So guess this would need to rewrite this completely in a language that allows precise control over memory.

[Atharva-Varpe]

Can I take this up?

Plan:

• Add a secure memory wrapper in Python, using ctypes to call libsodium's secure memory functions.
• Refactor key classes to store key material in this secure memory, not as Python bytes.

[ThomasWaldmann]

@Atharva-Varpe this might be a rather hard task with unsure outcome.

Also, as of now (guess that was different when I opened it), there are no plans to add libsodium to our dependencies (we use most crypto stuff either from openssl or from python).

Maybe check if there are other options. Also check whether it is feasable at all, considering my previous comment.