aol / mrcrypt Goto Github PK

We should add the ability to re-encrypt files that are using the old uncompressed points, as suggested by @mattsb42-aws in #8.

Related: #10

If the user is decrypting a file that was encrypted with an uncompressed key, we should print out a warning telling them this.

I know that we have previously discussed the possibility of mrcrypt migrating to use the AWS Encryption SDK for Python internally. However, now that we have released the AWS Encryption SDK CLI, I think that the best route to achieve this is to build on top of the CLI rather than the SDK directly.

The AWS Encryption SDK CLI provides all of the functionality of mrcrypt (with two exceptions that I discuss below), just with a different interface. So, what I think would make the most sense is to keep the mrcrypt parser and add a layer that translates the parsed arguments to arguments for the AWS Encryption SDK CLI.

I have a PoC put together on my fork that implements this. Before going any deeper, does this look like a direction that you would be interested in taking mrcrypt?

There are two places where the AWS Encryption SDK CLI (by design) does not match mrcrypt's feature set:

1. uncompressed ECDSA public keys
2. output file permissions

In the PoC, I address the uncompressed ECDSA public key problem with a custom cryptographic materials manager.

When we were looking at the question of what permissions to use for output files, we came to the conclusion that the AWS Encryption SDK CLI should not make any specific statements about the permissions, and instead simply honor the umask (on POSIX) or the parent directory permissions (on Windows). However, if you want to retain mrcrypt's behavior of setting specific permissions on the output files, this could be implemented by collecting the output metadata from the AWS Encryption SDK CLI, parsing it to determine what files were created, and changing the permissions on those files.