search

otrv4 / libotr-ng

A new implementation of OTR with support for version 4. This is a mirror of https://bugs.otr.im/otrv4/libotr-ng
Other
43 stars 9 forks source link

Persistence APIs for private keys that use a buffer, not a FILE. #204

Closed kaie closed 3 years ago

kaie commented 5 years ago

Thunderbird prefers to encrypt private keys before storing them on disk. It already does that for saved server logins, and for certificate private keys.

In order to handle the encryption and decryption of the persistent data produced by libotr, it would be helpful if the persistence APIs offered a function that returns the persistent data as a buffer, without writing it to a file. This could ensure that the private keys never reach the disk without protection. Similarly, reading the persistent data back should also support reading from a buffer, instead of a FILE.

claucece commented 5 years ago

Yes! I agree on this. I thought we had an issue for this already. Btw, @kaie .. maybe we can have a call? If I remember correctly, you wanted to help on some UI things... ;)

kaie commented 5 years ago

Regarding a potential call, could we coordinate by email? I don't have your address, but mine is public, can be found if you click my avatar. Thanks!

kaie commented 5 years ago

(You might confuse me with someone else regarding UI help. I currently focus on Thunderbird, and I had briefly touched coyim for a spam experiment and for a bugfix.)

Regarding this bug: github tracking seems to be about libotr-ng only, but I also need this improvement for the older libotr-4.1.1 lib, and I already had an experimental patch for it. I contacted Ian and Jurre by email to hear their opinion.

For libotr-ng, I could help with this bug, too. It's probably just a bit of refactoring for the persistence code you already have.

claucece commented 5 years ago

Hey!

(You might confuse me with someone else regarding UI help. I currently focus on Thunderbird, and I had briefly touched coyim for a spam experiment and for a bugfix.)

Maybe.. ahaha

Regarding this bug: github tracking seems to be about libotr-ng only, but I also need this improvement for the older libotr-4.1.1 lib, and I already had an experimental patch for it. I contacted Ian and Jurre by email to hear their opinion.

Yes, this is around libotr-ng only. You can open an issue for older versions here: https://bugs.otr.im/lib/libotr/issues

For libotr-ng, I could help with this bug, too. It's probably just a bit of refactoring for the persistence code you already have.

Sure! want to do so?

Thanks!

kaie commented 5 years ago

The old library used three separate files for storing fingerprints, instance tags and private keys. Will libotr-ng still use a separate file for the private keys?

Or will libotr-ng rather use a single combined file for all state information, that has the private keys somewhere in the middle?

Looking at persistence.c/h and test_persistence.c, you're testing identity export (you call otrng_client_export_v4_identity).

I don't see a test for isolated private key export (you don't call otrng_client_private_key_v4_write_to, which is only called from add_private_key_v4_to, which is only called from otrng_global_state_private_key_v4_write_to, which is never called).

In other words:

It's not clear to me, if you expect the application to store/manage private keys separately from the rest.

I don't know if buffer versions for otrng_client_private_key_v4_write_to and otrng_client_private_key_v4_read_from will be sufficient, or if we'll require buffer versions for all functions listed in persistence.h that currently take a FILE*.

claucece commented 5 years ago

Hey, @kaie !

Sorry for not reaching out.

The old library used three separate files for storing fingerprints, instance tags and private keys. Will libotr-ng still use a separate file for the private keys?

Yes! But we do have more data that we store: client and prekey profiles, shared prekey and a forging key. The are all stored in separate files.

Looking at persistence.c/h and test_persistence.c, you're testing identity export (you call otrng_client_export_v4_identity).

That is a different thing. It is for creating an identity based on the long-term forging and normal key.

I don't see a test for isolated private key export (you don't call otrng_client_private_key_v4_write_to, which is only called from add_private_key_v4_to, which is only called from otrng_global_state_private_key_v4_write_to, which is never called).

There is no test; but that is the correct function you are looking for.

I don't know if buffer versions for otrng_client_private_key_v4_write_to and otrng_client_private_key_v4_read_from will be sufficient, or if we'll require buffer versions for all functions listed in persistence.h that currently take a FILE*.

Those should already exist but not as exposed functions. See: https://github.com/otrv4/libotr-ng/blob/master/src/persistence.c#L66

claucece commented 3 years ago

I just exposed the function. Let me know if that helps you.