Request for recommendation - encryption and signature for file backup

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Request for recommendation - encryption and signature for file backup

Aham Brahmasmi
Namaste misc,

What tool(s) would you recommend to encrypt and sign a file - correctly
- for backup?

I possess a limited ability to read code, and I am certainly not a
cryptographer.

In my limited understanding, to securely backup and restore a file, the
steps are:

To backup:
Step 1 - encrypt the file using a tool
Step 2 - sign the encrypted file using a tool
Step 3 - backup the signature and the encrypted file

To restore:
Step 1 - verify the encrypted backup with its signature
If Step 1 exits with success,
Step 2 - decrypt backup to file
If Step 2 exits with success,
Step 3 - use file to restore

For the tools to encrypt and sign, I think I may use the following:

For encryption: encpipe
encpipe (https://github.com/jedisct1/encpipe) is ISC licenced, written
in C by Monsieur Denis and seems simple. If there is one thing that I
know - and I admit I don't know much - all things being equal, simple
beats complex.

However, I do not understand the math underlying the tool or whether all
things are indeed equal - possible attack vectors, mitigations et al.
And hence, my request.

For signature: signify
I think signify may suffice for signature. For other platforms, minisign
(https://github.com/jedisct1/minisign) is compatible with signify.

Dhanyavaad,
ab
---------|---------|---------|---------|---------|---------|---------|--

Reply | Threaded
Open this post in threaded view
|

Re: Request for recommendation - encryption and signature for file backup

Claus Assmann-4
Maybe duplicity? It's available as package (not sure
whether it does signing).

--
Address is valid for this mailing list only.

Reply | Threaded
Open this post in threaded view
|

Re: Request for recommendation - encryption and signature for file backup

Roderick
In reply to this post by Aham Brahmasmi

I would perhaps write a script that calls openssl for encripting and
signing, rsync to send new files, something simple.

I do use openssl for encrypting files in my laptop.

Rodrigo


On Thu, 2 Jan 2020, Aham Brahmasmi wrote:

> Namaste misc,
>
> What tool(s) would you recommend to encrypt and sign a file - correctly
> - for backup?
>
> I possess a limited ability to read code, and I am certainly not a
> cryptographer.
>
> In my limited understanding, to securely backup and restore a file, the
> steps are:
>
> To backup:
> Step 1 - encrypt the file using a tool
> Step 2 - sign the encrypted file using a tool
> Step 3 - backup the signature and the encrypted file
>
> To restore:
> Step 1 - verify the encrypted backup with its signature
> If Step 1 exits with success,
> Step 2 - decrypt backup to file
> If Step 2 exits with success,
> Step 3 - use file to restore
>
> For the tools to encrypt and sign, I think I may use the following:
>
> For encryption: encpipe
> encpipe (https://github.com/jedisct1/encpipe) is ISC licenced, written
> in C by Monsieur Denis and seems simple. If there is one thing that I
> know - and I admit I don't know much - all things being equal, simple
> beats complex.
>
> However, I do not understand the math underlying the tool or whether all
> things are indeed equal - possible attack vectors, mitigations et al.
> And hence, my request.
>
> For signature: signify
> I think signify may suffice for signature. For other platforms, minisign
> (https://github.com/jedisct1/minisign) is compatible with signify.
>
> Dhanyavaad,
> ab
> ---------|---------|---------|---------|---------|---------|---------|--
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Request for recommendation - encryption and signature for file backup

Aham Brahmasmi
In reply to this post by Claus Assmann-4
Hallo Claus,

Danke for your reply.

> Sent: Thursday, January 02, 2020 at 6:38 PM
> From: "Claus Assmann" <[hidden email]>
> To: [hidden email]
> Subject: Re: Request for recommendation - encryption and signature for file backup
>
> Maybe duplicity? It's available as package (not sure
> whether it does signing).

I apologize for not completely explaining my original query. I am aware
of backup tools that can encrypt and/or sign and/or deduplicate.
Duplicity, restic, borg et al.

I am trying to ascertain what tool would misc@ recommend to encrypt and
then sign the file. This encrypted file and its signature would then
be handed over to a backup tool - duplicity/restic/borg or even a custom
script.

In other words, it would be preferable for the backup tool to not do
cryptography, but pick up the file after it has been encrypted and
signed.

And hence, my request. I now understand that my original mail was not
at all clear on this. My mistake.

With respect to duplicity [1], if I am not wrong, it uses GnuPG for the
cryptography part.

I think the following blog post is quite informative about PGP, GnuPG et
al:

https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

That blog post itself links to the following paper by tedu@:

https://www.openbsd.org/papers/bsdcan-signify.html

I did not understand the cryptographic aspects of the latacora post, but
I understood that a dedicated file encryption tool was desirable. Also,
signify(1)/minisign would be a good fit for the signature part.

I understand that "age" as suggested in that blog post was recently
added to ports - Thanks abieber@ for that. However, if I am not wrong,
it is still in beta.

Dhanyavaad,
ab
[1] - http://duplicity.nongnu.org/
---------|---------|---------|---------|---------|---------|---------|--

Reply | Threaded
Open this post in threaded view
|

Re: Request for recommendation - encryption and signature for file backup

Aham Brahmasmi
In reply to this post by Roderick
Namaste Rodrigo,

Thank you for your reply.

> Sent: Friday, January 03, 2020 at 5:43 PM
> From: "Roderick" <[hidden email]>
> To: "Aham Brahmasmi" <[hidden email]>
> Cc: [hidden email]
> Subject: Re: Request for recommendation - encryption and signature for file backup
>
>
> I would perhaps write a script that calls openssl for encripting and
> signing, rsync to send new files, something simple.
>
> I do use openssl for encrypting files in my laptop.
>
> Rodrigo

If I am not wrong, some time ago, solene@ wrote a blog post about using
openssl for encrypting files. She later modified it to recommend
existing backup tools. I think there was some feedback with respect to
her usage of openssl and cryptography, but I do not exactly remember
what it was.

I cannot find the original blog post, but the modified one is available
at https://dataswamp.org/~solene/2018-06-26-openbsd-easy-backup.html

Perhaps, may be solene@ would be able to throw more light on the openssl
feedback.

>
> On Thu, 2 Jan 2020, Aham Brahmasmi wrote:
>
> > Namaste misc,
> >
> > What tool(s) would you recommend to encrypt and sign a file - correctly
> > - for backup?
> >
> > I possess a limited ability to read code, and I am certainly not a
> > cryptographer.
> >
> > In my limited understanding, to securely backup and restore a file, the
> > steps are:
> >
> > To backup:
> > Step 1 - encrypt the file using a tool
> > Step 2 - sign the encrypted file using a tool
> > Step 3 - backup the signature and the encrypted file
> >
> > To restore:
> > Step 1 - verify the encrypted backup with its signature
> > If Step 1 exits with success,
> > Step 2 - decrypt backup to file
> > If Step 2 exits with success,
> > Step 3 - use file to restore
> >
> > For the tools to encrypt and sign, I think I may use the following:
> >
> > For encryption: encpipe
> > encpipe (https://github.com/jedisct1/encpipe) is ISC licenced, written
> > in C by Monsieur Denis and seems simple. If there is one thing that I
> > know - and I admit I don't know much - all things being equal, simple
> > beats complex.
> >
> > However, I do not understand the math underlying the tool or whether all
> > things are indeed equal - possible attack vectors, mitigations et al.
> > And hence, my request.
> >
> > For signature: signify
> > I think signify may suffice for signature. For other platforms, minisign
> > (https://github.com/jedisct1/minisign) is compatible with signify.
> >
> > Dhanyavaad,
> > ab
> > ---------|---------|---------|---------|---------|---------|---------|--

Dhanyavaad,
ab
---------|---------|---------|---------|---------|---------|---------|--

Reply | Threaded
Open this post in threaded view
|

Re: Request for recommendation - encryption and signature for file backup

Philippe Meunier
In reply to this post by Roderick
>Aham Brahmasmi wrote:
>> In my limited understanding, to securely backup and restore a file, the
>> steps are:
>>
>> To backup:
>> Step 1 - encrypt the file using a tool
>> Step 2 - sign the encrypted file using a tool
>> Step 3 - backup the signature and the encrypted file
>>
>> To restore:
>> Step 1 - verify the encrypted backup with its signature
>> If Step 1 exits with success,
>> Step 2 - decrypt backup to file
>> If Step 2 exits with success,
>> Step 3 - use file to restore

The signature verification step is useless: if someone can change an
encrypted file on your backup system then they can change the corresponding
signature file on the same backup system too.

If you use (symmetric) encryption then there is probably no need for a
signature in your simple use case anyway: if the encrypted file correctly
decrypts (which is usually easy to tell for data files like text or images)
with the password that only you know then you can assume that nobody
changed the content of the encrypted file on your backup system.  If
someone changed the content of the encrypted file on your backup system
then, when you try to decrypt it, either the decrypt will fail or the
result will look like random garbage (hence the "usually easy" above).

If your goal is just to prevent people from looking at the content of your
file if they somehow access your backup system then encryption is really
all you need.  If you're worried that people might actively try to attack
you through your backup system then you have bigger problems which are
probably beyond what random people on a mailing list can help you with...

Roderick wrote:
>I do use openssl for encrypting files in my laptop.

So do I.  I only encrypt the 0.001% of files that are really important and
then those files are encrypted on my computer too, not just on the backup
system (because if a file is important enough to be encrypted on your
backup system then it's probably important enough to be encrypted on your
computer too).  Something like:

openssl enc -aes256 -e < foo > foo.aes256

then I delete foo.  (To decrypt use the -d option instead of -e; and read
carefully the openssl(1) man page before you type the command above because
you have no reason to trust me, right?)  Then I do backups without worrying
about whether a file is encrypted or not.  YMMV.

Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Request for recommendation - encryption and signature for file backup

Aham Brahmasmi
Namaste Philippe,

Merci beaucoup for your reply.

> Sent: Saturday, January 04, 2020 at 3:54 PM
> From: "Philippe Meunier" <[hidden email]>
> To: "Aham Brahmasmi" <[hidden email]>
> Cc: [hidden email], Roderick <[hidden email]>
> Subject: Re: Request for recommendation - encryption and signature for file backup
>
> >Aham Brahmasmi wrote:
> >> In my limited understanding, to securely backup and restore a file, the
> >> steps are:
> >>
> >> To backup:
> >> Step 1 - encrypt the file using a tool
> >> Step 2 - sign the encrypted file using a tool
> >> Step 3 - backup the signature and the encrypted file
> >>
> >> To restore:
> >> Step 1 - verify the encrypted backup with its signature
> >> If Step 1 exits with success,
> >> Step 2 - decrypt backup to file
> >> If Step 2 exits with success,
> >> Step 3 - use file to restore
>
> The signature verification step is useless: if someone can change an
> encrypted file on your backup system then they can change the corresponding
> signature file on the same backup system too.

I am not a cryptographer, and neither am I a math expert.

Let us assume that someone has access to the backup - both the encrypted
file and its signature. This person does not have access to the
encryption key and the private signing key - else this discussion is
moot.

This person changes the encrypted file and the corresponding signature
file as well. Now, when this modified file is verified against the
modified signature using the public signing key, would the verification
fail or succeed?

If I am not wrong, the verification should fail. In short, this is by
definition of signature itself. For a longer explanation, to generate a
valid signature, this person will need to have access to the private
signing key. Since this person does not have access to the private
signing key, the person can modify the encrypted file, but not generate
a valid signature of the modified encrypted file. And modifying the
original signature does not mean much - the verification with the public
signing key will fail.

For example, consider the OpenBSD release signing system. (I think)
Theo signs the releases using a private signing key. If I am not wrong,
only Theo has access to the private signing key, but we all have access
to the public signing key.

The bsd.rd is released along with its signature in the SHA256.sig file.
We run signify(1) to verify the bsd.rd with its signature in the
SHA256.sig file and the base.pub public signing key.

Let us assume I get access to the download server and I replace the
perl based installer with a rust based installer in the bsd.rd. I also
change the SHA256.sig file. I do not think I will fool anybody who uses
signify to verify the all-new-improved-rust-based-installer bsd.rd with
the base.pub.

And if you think I came up with this, no. I have only rehashed tedu@'s
paper on signify - https://www.openbsd.org/papers/bsdcan-signify.html

> If you use (symmetric) encryption then there is probably no need for a
> signature in your simple use case anyway: if the encrypted file correctly
> decrypts (which is usually easy to tell for data files like text or images)
> with the password that only you know then you can assume that nobody
> changed the content of the encrypted file on your backup system.  If
> someone changed the content of the encrypted file on your backup system
> then, when you try to decrypt it, either the decrypt will fail or the
> result will look like random garbage (hence the "usually easy" above).

For files like compressed database backups, I am not sure I can
determine whether a file has been correctly decrypted or not by looking
at whether the result looks like random garbage.

> If your goal is just to prevent people from looking at the content of your
> file if they somehow access your backup system then encryption is really
> all you need.  If you're worried that people might actively try to attack
> you through your backup system then you have bigger problems which are
> probably beyond what random people on a mailing list can help you with...

In the case of compressed database backups, it may also be possible that
the backup may have changed due to bit-rot. So decrypting the backup
and restoring it assuming no bit-rot may not be exactly preferable.

> Roderick wrote:
> >I do use openssl for encrypting files in my laptop.
>
> So do I.  I only encrypt the 0.001% of files that are really important and
> then those files are encrypted on my computer too, not just on the backup
> system (because if a file is important enough to be encrypted on your
> backup system then it's probably important enough to be encrypted on your
> computer too).  Something like:
>
> openssl enc -aes256 -e < foo > foo.aes256
>
> then I delete foo.  (To decrypt use the -d option instead of -e; and read
> carefully the openssl(1) man page before you type the command above because
> you have no reason to trust me, right?)  Then I do backups without worrying
> about whether a file is encrypted or not.  YMMV.

I am not sure about the openssl encryption. If I am not wrong, there was
some feedback shared on solene@'s blog post and she modified it based on
that feedback. Unfortunately, I do not remember what that feedback was.

> Philippe

Dhanyavaad,
ab
---------|---------|---------|---------|---------|---------|---------|--

Reply | Threaded
Open this post in threaded view
|

Re: Request for recommendation - encryption and signature for file backup

Roderick
In reply to this post by Philippe Meunier

On Sat, 4 Jan 2020, Philippe Meunier wrote:

> Roderick wrote:
> >I do use openssl for encrypting files in my laptop.
>
> So do I.  I only encrypt the 0.001% of files that are really important and
> then those files are encrypted on my computer too, not just on the backup
> system [...]

I have an encrypted partition, that I mount only when necessary. Perhaps
that is also an alternative for Aham: mount, send backup, umount.

Rodrigo

Reply | Threaded
Open this post in threaded view
|

Re: Request for recommendation - encryption and signature for file backup

Philippe Meunier
In reply to this post by Aham Brahmasmi
Aham Brahmasmi wrote:
>If I am not wrong, the verification should fail.

If you have a system that uses private / public signing keys then, yes,
you're correct.

But:

1) In my opinion it's probably overkill for just doing backups.  As I said
in my previous email, just using symmetric encryption and encrypting in
advance the few files you really care about is probably good enough and
simpler.

2) You'll have to remember to encrypt your private signing key (using some
symmetric encryption like aes256) before you make a backup of it.

>Let us assume I get access to the download server and I replace the
>perl based installer with a rust based installer in the bsd.rd. I also
>change the SHA256.sig file. I do not think I will fool anybody who uses
>signify to verify the all-new-improved-rust-based-installer bsd.rd with
>the base.pub.

That's right, because the public keys are already in /etc/signify and the
signature verification would fail.  The use of public / private keys here
is necessary because files are distributed to other people and these other
people must not have access to the private key.  In your case there is no
"other people" so using public / private keys is probably more than you
need.  A simple symmetric encryption with just a password would be good
enough in my opinion (but it's only my opinion, it's up to you to decide
what's best for you).

You have to ask yourself: what are the problems that I am trying to defend
against?  Then use the simplest solution that solves those problems.  Be
practical, and don't waste time trying to defend against threats which are
only theoretical.

>For files like compressed database backups, I am not sure I can
>determine whether a file has been correctly decrypted or not by looking
>at whether the result looks like random garbage.

Well, then, you have a good reason to use signatures.  Note that it still
does not require a public / private key system.  You could just compute a
hash of your DB (before encryption) and then store the hash on your backup
system (no need to encrypt the hash) together with the encrypted DB
(encrypted using symmetric encryption and a password).  Then later you
would:

1) decrypt the DB
2) compute the hash of the decrypted DB and check that it matches the hash
from the backup system.

Note that in that case the hash must be created *before* you encrypt the
DB, not after, otherwise you will not be able to detect a change done to
both the file and the hash on the backup system (as I said in my previous
email).

Anyway, it's up to you to decide what you want to do and whether you need a
hash and / or public / private keys, but my advice is to keep your system
as simple as possible.

Philippe