Add a utility to encrypt and decrypt files in the browser

[mgwalker]

Changes proposed in this pull request:

This PR adds a client-side tool that allows users to select files, enter a password, and download an encrypted copy of that file. Similarly, users can select an encrypted file, enter the password, and download a decrypted copy of it. This tool does not exchange any information with any servers anywhere – it uses the Web Crypto native web API to do all of its cryptography in the browser.

Direct link to the tool in preview

security considerations

tk,tk - Probably want to bounce this off the cloud.gov Pages team and/or AO to ensure that this doesn't violate anything about that system. Since all data resides on the user's computer and is never stored by cgPages, it seems like this should be fine.

[akf]

Change type to "password" so if someone's demoing this they don't inadvertently display the password?

[mogul]

To mitigate the possibility of a JS injection attack that grabs the file content and has its way with it, I would want to see the form for a utility like this presented in a page that literally imports no other JS. That's not the case for handbook pages:

[mgwalker]

Some intermediate changes in the latest push:

• the password field is masked by default, but there is a button to toggle the masking
• there's a new button for creating a random password
• passwords must be at least 16 characters per NIST recommendations

I'll push up some more stuff later that'll move this tool onto its own page that doesn't import any other Javascript.

I think there's also some consideration around whether and how we could protect this page from other JS injection attacks. My naive first thoughts:

• Cloud.gov Pages sets the X-Frame-Options header to SAMEORIGIN which should prevent browsers from embedding the Handbook as a frame in any other sites. The frame sandbox should also prevent sites from accessing data in the frame anyway, but defense in depth...
• The Handbook is served over TLS, which ostensibly should ensure the integrity of what we deliver to the client, unless there's a TLS-terminating proxy in the middle, which of course nobody would ever actually deploy... 🤦🏻‍♂️
• The repo requires PR reviews, which isn't an ironclad guarantee, but I think we consider it good enough elsewhere and I don't know why it wouldn't also be good enough here.