Securely share files in your team。
This repository allows to handle and share securely sensitive data by wisely using GNU Privacy Guard (GPG). It consists of a simple directory structure and a shell script named
Your sensitive data is stored in the
Files and top-level directories under
The
A file named
The
Since encrypted files cannot be read, an index file documenting the content of each of them is recommended, along with descriptive file names.
You share everything by pushing
File format of the
This file contains references to all keys which will be used as
recipients. Each line starting with the
What follows the
Besides the
If no key is provided in the keys file GPG will not be provided with
from https://github.com/dacav/secshare
This repository allows to handle and share securely sensitive data by wisely using GNU Privacy Guard (GPG). It consists of a simple directory structure and a shell script named
secshare
, which is a simple GPG
wrapper.Requisites
The helper script is designed to work under the following assumptions:-
Your team established a chain of trust:
All members should have signed each other's public keys. If you don't know what this means, you should read some good manual on how to do it: I would personally suggest this guide.
-
Your hard drive is encrypted:
The helper scripts of this repository will store sensitive information as plaintext on your hard drive. This is secure only if your disk is encrypted.
-
No revocation of granted access:
The script knows nothing about your data, and if someone leaves the team you probably want to consider all shared secret as compromised.
-
No fine-grained selection of access: all team has got access to all
files.
Concept
Fork the repository and clone it locally.Your sensitive data is stored in the
data
directory. Note that the
data
directory is added to the .gitignore
file and must never be
commited.Files and top-level directories under
data
are treated as distinct
sensitive items, so you can group together in the same top-level directory
any tree of related data.The
secshare
script encrypts each sensitive item as ascii-armored
gpg-encrypted tarball. Each encrypted file is stored in the
encrypted_data
directory.A file named
keys
will list the users which are allowed to access data.
This setting is honored by the secshare
script during the encryption
phase.The
keys
file is signed by one member of the team. This ensures
the keys
file to contain only authorized keys, hence avoiding an
attacker to put her key among the recipients of encryption. This step is
handled by secshare
, and generates a detached signature file named
keys.asc
.Since encrypted files cannot be read, an index file documenting the content of each of them is recommended, along with descriptive file names.
You share everything by pushing
encrypted_data
, keys
, keys.asc
and
the index file (if any)Helper script
Thesecshare
script is a simple helper program written in Bourne Shell
(sh). The following commands are supported:-
./secshare init
:
Initialize the repository unless it wasn't already initialized. This simply creates the filesystem structure and initializes thekeys
file;
-
./secshare close
:
Encrypt each sensitive item (file or directory) in thedata
directory. Put the resulting encrypted files in theencrypted_data
directory.
Recipients are obtained by reading thekeys
file (see the Keys file format section for details). The./secshare close
command will fail unless thekeys
file can be verified against a detached signaturekeys.asc
, and the signature was made by a trusted user.
(A trusted user is someone whose key was signed by you or another user you trust. Again, RTFM!).
-
./secshare sign
:
Sign thekeys
file with a detached signature. This is a required step in order for you and other team members to./secshare close
successfully. One should never sign blindly thekeys
file!
-
./secshare open
:
Open one or more files contained inencrypted_data
.
Files cannot be opened unless they were encrypted with the user's public key (via./secshare close
).
A pattern can be specified to ask for one or more files to be decrypted. If not specified, the script will try to decrypt all encrypted files.
File format of the keys
file:
This file contains references to all keys which will be used as
recipients. Each line starting with the pub:
prefix should identify a
public key.What follows the
pub:
prefix will be cut of white-space characters and
used as parameter for --recipient
in GPG. In other words the short id of
the key or an email address will work fine, but the full key fingerprint
is recommended.Besides the
pub:
lines, this file can contain arbitrary text, which will
be ignored by the secshare
script. This "feature" can be used to put
useful comments, as the name of the key owner.If no key is provided in the keys file GPG will not be provided with
--recipient
directives, and you will be interactively asked to provide a
recipient.from https://github.com/dacav/secshare
No comments:
Post a Comment