Cornel,
All good thoughts and questions. Your response encouraged me to Google a
little bit further beyond my baseline plan to just back up my secret key
via my local Time Machine routine.
Your mention of keeping a physical copy led me to Paperkey:
http://jpadilla.com/post/100355231982/backup-openpgp-keys-on-paper
Iıd be curious to know if others have had good success with that tool or
recommend others? Seems fairly straight-forward. Not sure how deep its
dependencies go or how well maintained it is, but it was easy to install
with homebrew and it appears that there are some developers working on
other implementations within GitHub. Iıll play with it more later.
As to the institutional complexities - yes your questions are spot on.
Less flexibility and more risk when it comes to managing the keys.
Thanks,
Matt Schultz
Metadata & Digital Curation Librarian
Grand Valley State University Libraries
[log in to unmask]
616-331-5072
On 3/31/16, 11:59 AM, "Code for Libraries on behalf of Cornel Darden Jr."
<[log in to unmask] on behalf of [log in to unmask]> wrote:
>Hello,
>
>Keeping track of keys has been a pain in the past for me. I still believe
>it's the best method. Now that I'm much more focused and organized it
>hasn't been a problem. But having a physical copy of the key tucked away
>will be helpful to me in the future. As far as institutional data, i can
>see some areas of concern. Who's keeping track of the keys? And is that
>info passed along with employment changes?
>
>Thanks,
>
>Cornel Darden Jr.
>Chief Information Officer
>Casanova Information Services, LLC
>Office Phone: (779) 205-3105
>Mobile Phone: (708) 705-2945
>
>Sent from my iPhone
>
>> On Mar 31, 2016, at 10:29 AM, Matt Schultz <[log in to unmask]> wrote:
>>
>> Hello,
>>
>> Iım writing to the list on a somewhat personal note. But I think any
>>responses to my question might also shed insights on future workflows in
>>my workaday world.
>>
>> I have a personal use case wherein I would like to store some encrypted
>>directories of data (at rest) on external hard drives. The idea being to
>>keep a full copy of some of my own personal data at an offsite location
>>in a secure format.
>>
>> I didnıt have the intermediate storage resources to image the full
>>backups that the target directories reside on - and there was too much
>>other file system overhead that was extraneous in any event. So, my
>>initial approach has been to make use of GPGTools and a pair of RSA keys
>>to encrypt tarballs of each of the desired directories. Iıve
>>successfully serialized, encrypted and passphrase decrypted the
>>directories. Iım using BagIt to validate on both sides and all is well
>>there. Everything appears to be working just fine for me. Larger
>>directories do take some time naturally RSA is a less efficient
>>algorithm as I understand it. That aside, I feel reasonably confident
>>that I can manage and migrate my keys going forward. Iım also
>>maintaining a duplicate nonencrypted backup of all of this data at home
>>as well in any event.
>>
>> My question is whether there are any limitations to use of RSA and the
>>approach I am taking to encrypting the contents in this serialized form?
>>Would anybody go about this in a different manner? Perhaps with
>>different tools? Iım out in front of the loss scenario in this case, so
>>I have the time/luxury to make some changes to how I am going about this
>>if I get some good advice.
>>
>> And then to the degree that the librarians, archivists, or records
>>managers on this list want to weigh-in, are there any emerging best
>>practices or compelling use cases you have encountered for encrypting
>>archives of your institutional data. If so, how did you weigh or
>>mitigate the benefits (privacy/security) against the risks (e.g,
>>mis-placing keys). Iım very interested in what the Records in the Cloud
>>Project is producing: http://www.recordsinthecloud.org/.
>>
>> Thanks,
>>
>> Matt Schultz
>> Metadata & Digital Curation Librarian
>> Grand Valley State University Libraries
>> [log in to unmask]<mailto:[log in to unmask]>
>> 616-331-5072
|
