This post introduces a new cryptography utility called CryptoTools. If you need a quick primer on cryptography, why not take a quick detour to my Introduction to Cryptography, Blade Runner Style post?
The Problem Link to heading
While working on the back end of Ghost Host, a privacy and security focused serverless web host, I realized we had a problem with password transmission security. Even though HTTPS secures the transmission of data from a client to a server, I don’t really know where sensitive data will end up. The old adage applies:
The cloud is just someone else’s computer.
My concern really is in logging. When enabling logging or tracing, it’s easy for passwords in plain text (or their hashed equivalents) to end up outside of their intended silo. I wondered how we might avoid using passwords altogether, but the Internet is still not quite ready to let go. Then I asked myself:
What Would Proton Do?
Proton migrated to the Secure Remote Password Protocol some time ago. I learned Apple also uses SRP for iCloud security code verification by their HSM clusters during keychain recovery. SRP isn’t widely known, but it is implemented by a few privacy-focused companies. I chose to implement it for Ghost Host as well.
Fundamentally, SRP is a password-authenticated key exchange protocol. A password is used to authenticate a user, but the neither the password nor any hashed derivative are stored or transmitted anywhere. Additionally, the protocol enables the user to authenticate the server, too. Neat! There are some steps that must be taken on both the client and the server to make this work, but I found myself in a situation where the front-end was not yet ready for the client-side implementation.
This problem prompted me to build a tool I had been considering for a long time. I call it CryptoTools, and I introduce it in this post.
Needs Link to heading
I wanted a cryptography playground for:
- Performing common cryptographic operations more easily,
- Validating the correctness of crypto system implementations, and
- Prototyping various cryptography tools and algorithms.
In the case of Ghost Host and the Secure Remote Password Protocol, CryptoTools implements both the server and client logic. It enabled me to build the server side components without a working front-end.
Existing Tools Link to heading
There are many existing tools online for hashing, encryption, etc, and some are really fantastic. But I thought many were suboptimal for several reasons:
- Nearly all of them have just a small collection of features with limited control and customization. I wanted a single place for anything I could need.
- More than half of the tools I evaluated process server-side. I wanted a solution I didn’t have to blindly trust, where all crypto operations happen on my device.
- Many were closed source or proprietary. I wanted to be able to audit the code.
- Some produced incorrect results due to either implementation bugs or due to false assumptions surrounding encodings.
- Finally, many were hard to use, not mobile friendly, and generally lacked good design.
I thought I would give it a go.
Design Link to heading
You might not have expected a blog post on cryptography to talk about design. But CryptoTools is primarily an experiment in design. The hypothesis is this: Can design make cryptography easier to use, and less prone to implementation error?
This bloke is Dieter Rams, an industrial designer whose designs for Braun’s consumer products have influenced many user interfaces in modern software. One notable example is Apple’s calculator app, which looks nearly identical to the Braun ET66 calculator. Rams’ design philosophy is, succinctly, “less, but better.” He established a list of ten design principles that I have kept up at my desk since the beginning of my career.
10 Principles of Good Design Link to heading
Good design is innovative.
Good design makes a product useful.
Good design is aesthetic.
Good design makes a product understandable.
Good design is unobtrusive.
Good design is honest.
Good design is long-lasting.
Good design is thorough down to the last detail.
Good design is environmentally friendly.
Good design is as little design as possible.
Whenever I start a new project or write a new feature, I look at this list. I can’t say that I’ve always succeeded in implementing every principle all the time, but I do try. Note that I don’t often design user interfaces. I apply these principles to code I write, cloud infrastructure I design, security controls I implement, and even to PowerPoint presentations I make.
I don’t know if I have succeeded in achieving a good design for CryptoTools. I invite you to be the judge. In any case, it is a living product that I will continue to improve with time. I hope you find it useful.
Features Link to heading
CryptoTools has several neat features in its infancy. Here is a list organized similarly to the tool:
- Digests
- Generate and verify SHA-1, SHA-256, SHA-384, and SHA-512 digests from input of arbitrary encoding
- Produce digests of multiple files simultaneously
- If a collection of files includes a SHASUMS file, all of the other files are automatically verified
- Secure Pseudo Random Number Generator
- Suitable for cryptographic applications (provided by browser)
- Generate random data of arbitrary length and encoding
- Generate random UUIDs
- Encryption
- Generate, export, and import CryptoKeys
- AES is supported in Counter, Cipher Block Chaining, and Galois Counter modes
- RSA is supported in Optimal Asymmetric Encryption Padding Mode, Signature with Appendix, and Probabilistic Signature Schemes
- HMAC is supported with SHA-1, SHA-256, SHA-384, and SHA-512
- ECDSA is supported with NIST curves P-256, P-384, and P-521
- CryptoKeys can be used to encrypt or decrypt arbitrary data (and files) using AES or RSA OAEP
- CryptoKeys can be used to sign or verify arbitrary data (and files) using RSA SSA PKCS#1 v1.5, RSA PSS, ECDSA, or HMAC
- All cryptography settings are tunable
- Keys can persist across page refreshes
- Keys can be deleted at any time
- Passwords
- Bcrypt hashing and verification (all settings tunable)
- PBKDF2 hashing
- SRP6a Registration, Authentication, and Identity Proof stages
Here is a hexadecimal-encoded SHA-256 digest of a file. There is a robust encoding system in CryptoTools. Many kinds of encodings are automatically detected, and some of these can be transformed arbitrarily. For instance, you can get your output as a binary, octal, hexadecimal, or base64 string. You can also get it in UTF-8. You can download results in their textual representations or in raw binary. Additionally, I tried to be helpful with the file names and extensions.
Safety Link to heading
All cybersecurity professionals should be asking themselves, is this safe? Fundamentally, this is a prototyping playground for learning, testing, and validating. Do not use it as your crypto system in a production application. That being said, I took a lot of care in making this tool safe and secure:
- All operations happen in the browser (there is no server; it’s a static site in an S3 bucket behind a CloudFront distribution)
- The code is open-source and auditable
- All commits are cryptographically signed
- All operations use the browser’s Web Crypto API when possible. Care was taken to select libraries with minimal to no dependencies
- There is a Software Bill of Materials
- Private/Secret keys are not accessible to scripts unless the key was generated or imported with the export option
- Storage of keys is in IndexedDB; the CryptoKey objects stored in the local DB only reference the secret/private key material. The browser handles their secure storage
- IndexedDB follows Same Origin policy
- HSTS, DNSSEC, Content Security Policy, and security headers are all implemented (A+ rating in Mozilla Observatory)
And of course, since the tool is free and open source, you can clone it and run it locally. Since the Web Crypto API requires a secure context, a web server is required for TLS, as well as a certificate. The docker environment takes care of all of this for you. Just clone and run docker compose up.
If you are worried about the security of CryptoKey storage using IndexedDb, Francisco Corella wrote a nice analysis in 2017. But you don’t have to persist keys at all.
What’s Next? Link to heading
You can see features and bug fixes in progress on the issues page. But here is a quick list:
- PGP Support
- X.509 (Certificates)
- SHASUMS file generation
- Operation Time calculations
- Warnings for insecure operation/configuration
- CryptoKey Derivation, i.e. from a password
- Safe Prime / Sophie Germain Prime Generation
- Yescrypt, scrypt, argon2 Password Hashing
Disclaimer Link to heading
I’m not a mathematician or a cryptologist. CryptoTools should be considered best effort. There may be errors or inaccuracies. If you find an error, please open an issue. CryptoTools is licensed under the GNU Public License version 3.