[gentoo-user] Encrypted backups under Gentoo

[gentoo-user] Encrypted backups under Gentoo

[Jan Seeger]

As per the subject:

I use luks-crypt to encrypt my home directory. Of course I would like
to make backups. These must, of course, also be encrypted. I have
tried duplicity, but when many changes have occured, this is
unbearably slow (being on a laptop). What would be the best solution
to back up with encryption barring duplicity?

Regards,
Jan Seeger
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Encrypted backups under Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]


On Thu, 2008-04-17 at 17:54 +0200, Jan Seeger wrote:
> As per the subject:
> 
> I use luks-crypt to encrypt my home directory. Of course I would like
> to make backups. These must, of course, also be encrypted. I have
> tried duplicity, but when many changes have occured, this is
> unbearably slow (being on a laptop). What would be the best solution
> to back up with encryption barring duplicity?
> 
> Regards,
> Jan Seeger

I personally use dar and gpg. Dar can be used to make incremental
backups which should partly solve your speed problem. Alternatively you
could use tar and gpg or cpio or whatever floats your boat.

The alternative would be an encrypted filesystem and rdiff-backup or
rsync. Optionally you could safe the key to the filesystem on your home
partition or, if it doesn't need to be automated, in a gpg-encrypted
file.

Let me know if you are interested in any of these options so I can
explain the details further (if you need support with that, that is).

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Encrypted backups under Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Thu, 17 Apr 2008 17:54:50 +0200, Jan Seeger wrote:

> I use luks-crypt to encrypt my home directory. Of course I would like
> to make backups. These must, of course, also be encrypted. I have
> tried duplicity, but when many changes have occured, this is
> unbearably slow (being on a laptop). What would be the best solution
> to back up with encryption barring duplicity?

I'm using duplicity and also found it slow, and it makes thousands of SSH
connections in the course of a day. I'm now testing app-backup/boxbackup,
which seems good so far.


-- 
Neil Bothwick

The road to HAL is paved with good intentions.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] Encrypted backups under Gentoo

[Jan Seeger]

At Thu, 17 Apr 2008 19:16:54 +0200,
Florian Philipp wrote:
> I personally use dar and gpg. Dar can be used to make incremental
> backups which should partly solve your speed problem. Alternatively you
> could use tar and gpg or cpio or whatever floats your boat.

Duplicity also does incremental backups, but it's still slow. Using
dar, would I have to "manually" (or per script) use gpg to encrypt the archives?

> The alternative would be an encrypted filesystem and rdiff-backup or
> rsync. Optionally you could safe the key to the filesystem on your home
> partition or, if it doesn't need to be automated, in a gpg-encrypted
> file.

An encryted filesystem and rdiff-backup or similar was another option
I though of. The problem is restoration: Would I easily be able to
restore the backups from a freshly installed system?

Regards,
Jan

-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Encrypted backups under Gentoo

[Chris Walters]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Florian Philipp wrote:
| On Thu, 2008-04-17 at 17:54 +0200, Jan Seeger wrote:
|> As per the subject:
|>
|> I use luks-crypt to encrypt my home directory. Of course I would like
|> to make backups. These must, of course, also be encrypted. I have
|> tried duplicity, but when many changes have occured, this is
|> unbearably slow (being on a laptop). What would be the best solution
|> to back up with encryption barring duplicity?
|>
|> Regards,
|> Jan Seeger
|
| I personally use dar and gpg. Dar can be used to make incremental
| backups which should partly solve your speed problem. Alternatively you
| could use tar and gpg or cpio or whatever floats your boat.
|
| The alternative would be an encrypted filesystem and rdiff-backup or
| rsync. Optionally you could safe the key to the filesystem on your home
| partition or, if it doesn't need to be automated, in a gpg-encrypted
| file.
|
| Let me know if you are interested in any of these options so I can
| explain the details further (if you need support with that, that is).

I also use dar, but I don't bother with gpg.  I use the '-K:' option of dar,
which provides passphrase protected blowfish protection.  I suppose I could use
gpg, as well, with AES256 or IDEA, but that would be overkill, I think, since I
keep my backups on an external USB port drive.

Chris
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJIB5j7AAoJEIAhA8M9p9DA+ccP/AqbWUYZMc76kiRa1nqL1A81
rDqrTomadkHoyqCgl0sXwmz85kEzgV33QP/yqrnSwAXQisDgvyQ9v8INOGff1p7D
e2Rw3U+31/U+xz1dMYTS8ucLKLKwMkU1m9+iIkRBbPDJPTVyUzup33RoV8Bt00oF
5241fYPhJQsLd/zwiYsUk6w7NO+4xyW7x9n2FXbOKZGuwSNT+0mVwXX/fDlvXhJJ
awkQMAfpv2vVQ5Y5+ovlhawECU/mv1BxOTrYB9M0jViT9ugKcoJEhJyONLra0LBL
1dwy/6g5PB+4RB/xKXZqJdO02gp7vqf3H2rlA6qcj+O0/b8gK5Jl1/QP2duzdgL5
XbChyiVfF5KTEB9EgAUuhrIMr+At5rinxFQmu0S8ohgoHRakFXAIhv7+DX6rkKJD
Y5Jf8X6sV+Flqac4dD9znmb98RgcbVTEyHLLKKPrvZ2mcEhRCw6I+HXcnYvFQV57
xEXbYEkKTXHlb6OFWOSC/ynvhw87mBz+Zjx0trm61awrgYBBgYoSBJk3nemjtL9e
0yslvgzMOClTjSlC9lgnCmiQDQNgFFgIUHSmrt/yfQ69jrluii7hvWJfRfFsu9i1
5wOnzOt5fI1sTxOoX9yMEXK+PjEgncdBVPMMF+dMvan4vyxGpAPwgzQSedgWPbgI
dwBz2ugEZAAsV0EszSQS
=mGmy
-----END PGP SIGNATURE-----
-- 
gentoo-user@lists.gentoo.org mailing list

[gentoo-user] Re: Encrypted backups under Gentoo

[Remy Blank]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

Neil Bothwick wrote:
> I'm now testing app-backup/boxbackup,
> which seems good so far.

Please report your findings on the list! I'm not all too happy about my 
current solution (rdiff-backup locally to a filesystem over dmcrypt, 
loopback-mounted from a file, followed by an rsync over ssh to a remote 
host), and I'd be happy to find something better!

-- Remy


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Encrypted backups under Gentoo

[Jan Seeger]

At Thu, 17 Apr 2008 14:37:52 -0400,
Chris Walters wrote:
> I also use dar, but I don't bother with gpg.  I use the '-K:' option of dar,
> which provides passphrase protected blowfish protection.  I suppose I could use
> gpg, as well, with AES256 or IDEA, but that would be overkill, I think, since I
> keep my backups on an external USB port drive.

This sounds like a feasible solution, I will try it out. Thanks for
the idea, Florian and Chris. 

I'm just wondering what the dar64 and dar32 useflags do...
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Encrypted backups under Gentoo

[Chris Walters]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jan Seeger wrote:
| At Thu, 17 Apr 2008 14:37:52 -0400,
| Chris Walters wrote:
<snip>
| This sounds like a feasible solution, I will try it out. Thanks for
| the idea, Florian and Chris.
|
| I'm just wondering what the dar64 and dar32 useflags do...

As I understand it, dar32 uses 32 bit integers and dar64 uses 64 bit integers,
I believe to represent file and archive sizes.  The description on the the USE
flag dar64 on the Gentoo site says, "Enables --enable-mode=64 option, which
replace infinint by 64 bits integers."  The dar32 option is described in the
same way, only with 32 replacing 64.

Regards,
Chris
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJIB6nGAAoJEIAhA8M9p9DAfPMP/RsttxEQmsX1EF0Ztilhkxox
dRHX+h5A723LGDgs0eDCG32qn+PMFpFzpRaYlT6k/zk82QwVXcBzDaPse9/REzch
eze1sItugrts5tB+j8VosNC9w7EvtvHq4R3cD56OoJ4xz0C7ywdUQvO2eTUJ7z8s
QklhRcY3flb4UIiVD/RmcB7TjY5mnJ9y4HqYq1pjgZxeAGWztJlXnQQbcO1tFST8
x8C2rgkT8A9LcyNm/leyQHmU6leys9flGWrr6q4g26Qvf9dPimPn0BnbPROmGEhJ
+eF3UFqR/ir4+JSeiDFzS0XuPN3id3C3n90qWawPeWEbmCnGazAepvH/P68hkPRV
bSb9ehhLwE2OjsiQg66zWKB3ZnVYKK+8MglddZUtGfAKVhxr53gbqhVolzZ0cE5a
pLbAz9zPoMfkQewQJux+ECoAwFRuOeV29wRXDuvb4sxTWN/Z3rvPFDvPgPjBClK1
uV1gKFRfE93N6NBAPkJHF8UlBjVN+LY4kqWmgFMjU3SnRBkw1HjwLMeaWh3qGdkC
R39i3GvE57M8X6YXOyFf2WtxDRzzLcyv/a1DvkVbr0uGVZAjkePgnldzCj5snoIw
+xY+3H9Y0MydrjuohdlrWj0davI+tG0lfM/FuV3e7Zl/zxYHr8QFWzYx8hgf3UUJ
+Om6MbxFsyo59mxF56W5
=758z
-----END PGP SIGNATURE-----
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Re: Encrypted backups under Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On Thu, 17 Apr 2008 20:57:47 +0200, Remy Blank wrote:

> > I'm now testing app-backup/boxbackup,
> > which seems good so far.  
> 
> Please report your findings on the list! I'm not all too happy about my 
> current solution (rdiff-backup locally to a filesystem over dmcrypt, 
> loopback-mounted from a file, followed by an rsync over ssh to a remote 
> host), and I'd be happy to find something better!

I'm currently using it with a local server. If I decide to use the
backups on a remote server too, I'll probably stick to backing up to the
local server and then using rsync. It makes sense to have a copy of the
backup locally and only use the much slower option of restoring from a
remote host when absolutely necessary.


-- 
Neil Bothwick

Top Oxymorons Number 36: Alone together

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] Encrypted backups under Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]


On Thu, 2008-04-17 at 20:05 +0200, Jan Seeger wrote:
> At Thu, 17 Apr 2008 19:16:54 +0200,
> Florian Philipp wrote:
> > I personally use dar and gpg. Dar can be used to make incremental
> > backups which should partly solve your speed problem. Alternatively you
> > could use tar and gpg or cpio or whatever floats your boat.
> 
> Duplicity also does incremental backups, but it's still slow. Using
> dar, would I have to "manually" (or per script) use gpg to encrypt the archives?

I use GPG instead of DAR's build-in encryption because asymmetric
encryption allows complete automation of the backup process, e.g. you
don't have to store the key as a plaintext file or type it at every
backup.

And yes, you need a custom script. For incremental backups to work you
would need to make an "isolated catalogue" (dar's nomenclature) in order
for it to see which files and timestamps are already backuped without
decrypting the archive. Tar uses a similar approach.

> 
> > The alternative would be an encrypted filesystem and rdiff-backup or
> > rsync. Optionally you could safe the key to the filesystem on your home
> > partition or, if it doesn't need to be automated, in a gpg-encrypted
> > file.
> 
> An encryted filesystem and rdiff-backup or similar was another option
> I though of. The problem is restoration: Would I easily be able to
> restore the backups from a freshly installed system?

AFAIK cryptsetup is part of Gentoo's stage3. Most live-CD's I've tried
had support for it, too. Commonly they also offer all common encryption
modules for the kernel and GPG, so I wouldn't worry about this. Just
make sure to keep your key and everything you need to decrypt off site.
I myself store my GPG-key on a server, my parent's PC and my USB-stick.

Since rdiff-backup stores all its internal data in a single directory,
(.rdiff-backup, I think) you could still access the last snapshot of
your system even without the program itself.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Encrypted backups under Gentoo

[Remy Blank]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

Neil Bothwick wrote:
> I'm currently using it with a local server. If I decide to use the
> backups on a remote server too, I'll probably stick to backing up to the
> local server and then using rsync. It makes sense to have a copy of the
> backup locally and only use the much slower option of restoring from a
> remote host when absolutely necessary.

There are at least two drawbacks to using rsync for mirroring the local 
backup to a remote host:

  - If your local backup becomes corrupt, then so does your remote 
backup, except if you are quick enough to disable the rsync step.

  - If you have disconnection during the rsync step (happened to me last 
night), your remote backup is temporarily corrupted.

For the second problem, I'm toying with the idea of writing an 
rsync-like tool for mirroring one big file to a remote server, by first 
transmitting the changes and storing them separately on the remote 
machine, then performing the update on the big file after the connection 
has closed.

-- Remy


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] Re: Encrypted backups under Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Fri, 18 Apr 2008 09:34:49 +0200, Remy Blank wrote:

> There are at least two drawbacks to using rsync for mirroring the local 
> backup to a remote host:
> 
>   - If your local backup becomes corrupt, then so does your remote 
> backup, except if you are quick enough to disable the rsync step.

That's a potential problem with any form of backup, local or remote. The
truly paranoid would use two different backup methods on two physically
separate destinations.

>   - If you have disconnection during the rsync step (happened to me
> last night), your remote backup is temporarily corrupted.

That should be fixable by having the script that runs rsync check the
return value and try again if it fails.


-- 
Neil Bothwick

The original point and click interface was a Smith & Wesson.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] Re: Encrypted backups under Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]


On Fri, 2008-04-18 at 09:34 +0200, Remy Blank wrote:
> Neil Bothwick wrote:
> > I'm currently using it with a local server. If I decide to use the
> > backups on a remote server too, I'll probably stick to backing up to the
> > local server and then using rsync. It makes sense to have a copy of the
> > backup locally and only use the much slower option of restoring from a
> > remote host when absolutely necessary.
> 
> There are at least two drawbacks to using rsync for mirroring the local 
> backup to a remote host:
> 
>   - If your local backup becomes corrupt, then so does your remote 
> backup, except if you are quick enough to disable the rsync step.

That's why I use rdiff-backup.
> 
>   - If you have disconnection during the rsync step (happened to me last 
> night), your remote backup is temporarily corrupted.
> For the second problem, I'm toying with the idea of writing an 
> rsync-like tool for mirroring one big file to a remote server, by first 
> transmitting the changes and storing them separately on the remote 
> machine, then performing the update on the big file after the connection 
> has closed.

Shouldn't rsync do this on its own? There is an option --inplace
described with:

"This causes rsync not to create a new copy of the file and then move it
into place.  Instead rsync  will  overwrite  the existing  file,
meaning that the rsync algorithm can't accomplish the full amount of
network reduction it might be able to otherwise (since it does not yet
try to sort data matches).  One exception to this is if you combine the
option  with --backup, since rsync is smart enough to use the backup
file as the basis file for the transfer.
This  option  is  useful for transfer of large files with block-based
changes or appended data, and also on systems that are disk bound, not
network bound.

The option implies --partial (since an interrupted transfer does not
delete the file), but conflicts with  --partial-dir and --delay-updates.
Prior to rsync 2.6.4 --inplace was also incompatible with --compare-dest
and --link-dest.

WARNING:  The  file's  data will be in an inconsistent state during the
transfer (and possibly afterward if the transfer gets interrupted), so
you should not use this option to update files that are in use.  Also
note  that  rsync  will be unable to update a file in-place that is not
writable by the receiving user."


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: Encrypted backups under Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Fri, 18 Apr 2008 10:44:05 +0200, Florian Philipp wrote:

> >   - If your local backup becomes corrupt, then so does your remote 
> > backup, except if you are quick enough to disable the rsync step.  
> 
> That's why I use rdiff-backup.

rdiff-backup isn't really suitable for offsite backups because it uses no
compression, making the space and bandwidth requirements double those of
other methods. It also uses no encryption.

Duplicity is by the same author and is aimed more at offsite backups.


-- 
Neil Bothwick

Windows Error:01F Reserved for future mistakes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] Re: Encrypted backups under Gentoo

[John covici]

on Friday 04/18/2008 Neil Bothwick(neil@digimed.co.uk) wrote
 > On Fri, 18 Apr 2008 09:34:49 +0200, Remy Blank wrote:
 > 
 > > There are at least two drawbacks to using rsync for mirroring the local 
 > > backup to a remote host:
 > > 
 > >   - If your local backup becomes corrupt, then so does your remote 
 > > backup, except if you are quick enough to disable the rsync step.
 > 
 > That's a potential problem with any form of backup, local or remote. The
 > truly paranoid would use two different backup methods on two physically
 > separate destinations.
 > 
 > >   - If you have disconnection during the rsync step (happened to me
 > > last night), your remote backup is temporarily corrupted.
 > 
 > That should be fixable by having the script that runs rsync check the
 > return value and try again if it fails.

Would not these problems be solved by something like rdiff-backup
which I have been using for a short time.  Its not encrypted, however
and I am not sure what happened to the developer, but it does seem to
work.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Re: Encrypted backups under Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]


On Fri, 2008-04-18 at 09:54 +0100, Neil Bothwick wrote:
> On Fri, 18 Apr 2008 10:44:05 +0200, Florian Philipp wrote:
> 
> > >   - If your local backup becomes corrupt, then so does your remote 
> > > backup, except if you are quick enough to disable the rsync step.  
> > 
> > That's why I use rdiff-backup.
> 
> rdiff-backup isn't really suitable for offsite backups because it uses no
> compression, making the space and bandwidth requirements double those of
> other methods. It also uses no encryption.

It uses compression (gzip), but only for increments.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: Encrypted backups under Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Fri, 18 Apr 2008 12:06:39 +0200, Florian Philipp wrote:

> > rdiff-backup isn't really suitable for offsite backups because it
> > uses no compression, making the space and bandwidth requirements
> > double those of other methods. It also uses no encryption.  
> 
> It uses compression (gzip), but only for increments.

Exactly, the current data backed up is as on the original filesystem,
unencrypted and uncompressed. This does make for incredibly easy
restoration, needing only cp, but isn't really suitable for offsite use.
Duplicity is better in this respect, but uses excessive amounts of
bandwidth.


-- 
Neil Bothwick

What did the first man to discover you can get milk from cows think he
was doing? - anon.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-user] Re: Encrypted backups under Gentoo

[Remy Blank]

[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]

>>   - If your local backup becomes corrupt, then so does your remote 
>> backup, except if you are quick enough to disable the rsync step.
> 
> That's why I use rdiff-backup.

Yes, me too, but *inside* the encrypted container.

>>   - If you have disconnection during the rsync step (happened to me last 
>> night), your remote backup is temporarily corrupted.
> 
> Shouldn't rsync do this on its own? There is an option --inplace
> described with:
> 
> "This causes rsync not to create a new copy of the file and then move it
> into place.  Instead rsync  will  overwrite  the existing  file,
> meaning that the rsync algorithm can't accomplish the full amount of
> network reduction it might be able to otherwise (since it does not yet
> try to sort data matches).  One exception to this is if you combine the
> option  with --backup, since rsync is smart enough to use the backup
> file as the basis file for the transfer.
> This  option  is  useful for transfer of large files with block-based
> changes or appended data, and also on systems that are disk bound, not
> network bound.
> 
> The option implies --partial (since an interrupted transfer does not
> delete the file), but conflicts with  --partial-dir and --delay-updates.
> Prior to rsync 2.6.4 --inplace was also incompatible with --compare-dest
> and --link-dest.
> 
> WARNING:  The  file's  data will be in an inconsistent state during the
> transfer (and possibly afterward if the transfer gets interrupted), so
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> you should not use this option to update files that are in use.  Also
> note  that  rsync  will be unable to update a file in-place that is not
> writable by the receiving user."

Yes, I use --inplace, but it will still leave the remote backup 
inconsistent in case of an interrupted transfer. And not using it is not 
an option for a 25GB file (and paying for capacity on the receiving end).

-- Remy


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-user] Re: Encrypted backups under Gentoo

[Remy Blank]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

Neil Bothwick wrote:
>>   - If your local backup becomes corrupt, then so does your remote 
>> backup, except if you are quick enough to disable the rsync step.
> 
> That's a potential problem with any form of backup, local or remote. The
> truly paranoid would use two different backup methods on two physically
> separate destinations.

Well, it's not quite the same. In the 2-step case (local backup, e.g. 
using rdiff-backup, followed by an rsync of the backup to a remote 
location), if your local backup gets corrupted, then so does your remote 
one.

If you just do two independent backups, even with the same method, one 
locally and the second remotely, if one gets corrupted, chances are the 
other one is still ok.

>>   - If you have disconnection during the rsync step (happened to me
>> last night), your remote backup is temporarily corrupted.
> 
> That should be fixable by having the script that runs rsync check the
> return value and try again if it fails.

You're right, of course. I would still be more comfortable keeping the 
"window of vulnerability" (the time for which the remote file is 
inconsistent) as small as possible, and independent of network 
connectivity. That's why I was thinking in the lines of "calculate diff, 
send diff and store remotely, update remote copy when connection has 
closed".

-- Remy


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]