summaryrefslogtreecommitdiff
path: root/bugs/lock-key-in-ram.mdwn
blob: a65396a3dae20f9d0add24deb89a3ef76559628f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[[!tag obnam-wishlist]]

Joey asked:

<joeyh> have you done anything in obnam to deal with it needing to keep
the symmetric key, decrypted, in RAM?

<joeyh> yeah, it's tough. probably could be avoided by having gpg decrypt
the passphrase and pipe it to the encrypting gpg .. but then gpg would
constantly be using the public key

It might be possible to have a C extension that holds the symmetric
key, locks it into RAM, and feeds it to gpg whenever necessary,
via a file descriptor.

--liw


I'm going to be switching from running gpg for symmetric encryption
in the future, anyway. I'll be doing symmetric encryption in-process
using python-crypt, and that means a lot of the sensitive data is going
to be in Python strings anyway. Locking anything in memory doesn't seem
feasible. [[done]] --liw