[Cryptography] Best/simplest document encryption

[Tom Mitchell]

On Fri, Mar 22, 2019 at 9:54 AM Henry Baker <hbaker1 at pipeline.com> wrote:

> At 06:13 PM 3/21/2019, Yoav O Yerushalmi wrote:
> >Have you looked at existing tool/systems like hush mail or protonMail ?
>
..

> >> What is the best (most secure & easiest to
> >> use) system for *non-crypto* people to use
> >> who have different platforms?
>
 ....

> In particular, I didn't want encryption built into:
>
> * email
> * browsers
> * compression (e.g., 'zip')
> * pdf
>

I assume you do want compression.
And I assume before encryption.
Data compresses differently so compression needs to be adaptive.
Abuse of decompression bombs intentional or not is a consideration.

The reuse of pass phrases and keys requirement  opens a lot of questions
and is in isolation is itself a project.
Even if secrets are well hashed the phrases and keys information needs to
be well managed.
So there is hidden in this a pass word management function a key management
tool specification.
That is a difficult topic.  It need not be all present at day one but for
sure thought through so it can
all be addressed.

The key management tool likely needs to stand alone and may need an audit
function
for businesses.   What is the life of these keys and phrases?   If six
months
and three are sent a day then there is a 3x180 FIFO rolling key set to
manage.
If different packages have different retention requirements then the meta
data needs
a date and retention policy.  The key management tool might need
integration into the
packaging system for usability but keeping secrets in a multi purpose tool
is a security
risk...

A key management tool seems central to this project.
It needs to remember keys sent to you, remember keys used, as well as keys
generated.
It needs a function "Was this used before?" which need only test a table of
hashed keys which is still a risk to protect.
In an audit litigious world with millions of $$ on the line some proof that
the data intended to be sent was sent and the key communicated correctly
makes sense.
The packaged collection of files  implies multiple authors and tracking.
Thus the table of contents (meta data) of the package likely needs digital
signatures.
Payment schedule.doc signed by finance, engineering documents signed by
engineering.
contract draft signed by legal. marketing names and stuff signed by
marketing eyes only too,
test-results.doc, change-log.doc.

Each sub document author's keys need to be managed and verified.   The
packager
needs to sign the package then deliver it.   The package structure may need
compartments
and internally have encrypted and signed content.  The package author can
verify keys
that may not need to be verified by others.

Simply sharing the encryption key allows any with the shared pass phrase
the opportunity to alter
and encrypt the package thus as evidence and for contracts there is no
value only safety
while in transport.  The structure of the package needs to allow signatures
and integrity checks.

Should keys be archived, purgeable or revokable in the key management
process.
If the employee doing the packaging can a transfer be made.
Can management audit, should management adit.

Done correctly and portably this is a product itself.

A simple person2person transfer is simple.  The party line games are more
interesting and
big money implies an audit trail.



-- 
   T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190322/4c89fd44/attachment.html>