[NBLUG/talk] Encrypting Files for Cloud Backup
Omar Eljumaily
omar at omnicode.com
Sat Apr 16 07:03:05 PDT 2016
I've never heard of a server side cloud encryption hack. Maybe you can
give some examples.
On 4/16/2016 6:33 AM, Aaron Grattafiori wrote:
>
> 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
> <mailto: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 <mailto: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>
>>> <mailto: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>
>>>> <mailto: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
>>>> <mailto: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 <mailto:talk at nblug.org>
>>>> http://nblug.org/cgi-bin/mailman/listinfo/talk [2]
>>>>
>>>> _______________________________________________
>>>> talk mailing list
>>>> talk at nblug.org <mailto:talk at nblug.org>
>>>> http://nblug.org/cgi-bin/mailman/listinfo/talk [2]
>>> _______________________________________________
>>> talk mailing list
>>> talk at nblug.org <mailto: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 <mailto:talk at nblug.org>
>>> http://nblug.org/cgi-bin/mailman/listinfo/talk
>> _______________________________________________
>> talk mailing list
>> talk at nblug.org <mailto:talk at nblug.org>
>> http://nblug.org/cgi-bin/mailman/listinfo/talk
>
>
> _______________________________________________
> talk mailing list
> talk at nblug.org <mailto: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/4e456834/attachment-0001.html>
More information about the talk
mailing list