[NBLUG/talk] Encrypting Files for Cloud Backup

Aaron Grattafiori aaron at digitalinfinity.net
Sat Apr 16 06:33:50 PDT 2016


Server side encryption isn't really a secure solution for most threat
models, including typical cloud backup scenarios.

Client side encryption is a better option, via something like duplicity,
although you then have to remember to backup the (strongly password
protected) encryption key somewhere.

-Aaron
On Apr 16, 2016 7:25 AM, "Omar Eljumaily" <omar at omnicode.com> wrote:

> Amazon seems to offer encryption through a setting.  That may be easier
> than what you're attempting.
> https://aws.amazon.com/blogs/aws/new-amazon-s3-server-side-encryption/
>
> I use Google cloud, and they encrypt as a standard feature.
>
> https://cloud.google.com/storage/docs/gsutil/addlhelp/SecurityandPrivacyConsiderations#encryption-at-rest
>
> All Google Cloud Storage data are stored encrypted. For more information
> see Server-Side Encryption
> <https://cloud.google.com/storage/docs/concepts-techniques#encryption>.
>
> You can also provide your own encryption keys. For more information, see
> ``
> <https://cloud.google.com/storage/docs/gsutil/addlhelp/SecurityandPrivacyConsiderations#id1>gsutil
> help encryption
> </storage/docs/gsutil/addlhelp/SupplyingYourOwnEncryptionKeys>`_`.
>
> On 4/15/2016 7:35 PM, gandalf at sonic.net wrote:
>
> Hey, thanks. This looks real good. I'll start digging into it next week. I
> have even found a elaborate setup script just for Amazon.
>
> On 2016-04-15 19:14, Aaron Grattafiori wrote:
>
> Checkout duplicity...
> On Apr 15, 2016 8:13 PM, <gandalf at sonic.net> <gandalf at sonic.net> wrote:
>
> Well I just got something working and am setting it up to work over
> the weekend.
>
> tar -zcf - -C /backups/servers itdocs | openssl enc -aes-256-cbc
> -salt -pass file:/etc/backups/key.bin | aws s3 cp -
> s3://XXXXXXX/servers/itdocs.160415.tar.gz.aes
>
> I was able to reverse the command and have it create a fresh itdocs
> folder full of goodies in a tmp folder. The key.bin file is 2048
> bytes of randomness:
>
> openssl rand -base64 2048 -out key.bin
>
> Is this any good? The sample I had only used 128 and I thought 2048
> would be better.
>
> I don't know how good this all is as backup encryption, but it
> looks like it should be as good as most. I'm not sure how it's going
> to handle the larger backups, but I guess I'll find out on Monday.
> It's set to do half Saturday morning and half Sunday morning.
>
> On 2016-04-15 18:46, Zack Zatkin-Gold wrote:
> I was about to say -- usually when you see malloc errors in a piece
> of
> software, it's because that software is unable to allocate more
> memory!
>
> On Fri, Apr 15, 2016 at 9:19 PM,  <gandalf at sonic.net> <gandalf at sonic.net>
> wrote:
> I think I found the problem. The method works for large files but
> openssl
> loads the entire file into memory and hence it needs one gigabyte
> of memory
> available for every gigabyte of file. This method isn't going to
> work to
> encrypt a 500gig file and indeed breaks on my two gig test backup.
>
> Anybody have any suggestions for encrypting very large backup
> files?
>
> On 2016-04-15 15:41, gandalf at sonic.net wrote:
>
> I was looking for a way to encrypt files using a key or keys and
> found
> this article:
>
>
>
> https://blog.altudov.com/2010/09/27/using-openssl-for-asymmetric-encryption-of-backups/#comment-399
>
> [1]
>
> I tied it out and it worked, but oddly when I moved the keys to a
> different folder openssl said it couldn't find them. Of course I
> adjusted the encryption/description commands to point to the proper
> files. I moved them back to /root and suddenly they work.
>
> Here's the command the article says to use to create keys:
> openssl req -x509 -nodes -days 100000 -newkey rsa:2048 -keyout
> MyCompanyBackupsPRIVATE.pem -out MyCompanyBackupsPublicCert.pem
> -subj
> '/'
>
> Here's one of the errors I got:
> root at vault:/etc/backups/tmp# openssl smime -in
> itdocs.160415.tar.gz.aes -decrypt -binary -inform DEM -inkey
> ../MSRI-Backups-PRIVATE.pem | tar -zx -f -
> Error reading S/MIME message
> 139777656317600:error:07069041:memory buffer
> routines:BUF_MEM_grow_clean:malloc failure:buffer.c:159:
> 139777656317600:error:0D06B041:asn1 encoding
> routines:ASN1_D2I_READ_BIO:malloc failure:a_d2i_fp.c:242:
>
> gzip: stdin: unexpected end of file
> tar: Child returned status 1
> tar: Error is not recoverable: exiting now
>
> Moved the pem files back to /root and everything works great.
> Although
> I find this reassuring I also find it disturbing as these keys are
> for
> encrypting backups and they may have to be manually typed in on a
> new
> system and used to restore an offsite backup from a disaster. I'd
> like
> to know that I can put these keys in folder and use them to decrypt
> backups.
>
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/cgi-bin/mailman/listinfo/talk [2]
>
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/cgi-bin/mailman/listinfo/talk [2]
>
>  _______________________________________________
>  talk mailing list
>  talk at nblug.org
>  http://nblug.org/cgi-bin/mailman/listinfo/talk [2]
>
>
> Links:
> ------
> [1]
>
> https://blog.altudov.com/2010/09/27/using-openssl-for-asymmetric-encryption-of-backups/#comment-399
> [2] http://nblug.org/cgi-bin/mailman/listinfo/talk
>
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/cgi-bin/mailman/listinfo/talk
>
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/cgi-bin/mailman/listinfo/talk
>
>
>
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/cgi-bin/mailman/listinfo/talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nblug.org/pipermail/talk/attachments/20160416/4fcac15a/attachment.html>


More information about the talk mailing list