-
-
Notifications
You must be signed in to change notification settings - Fork 2
3 FAQ
No, Tempel is explicitly not designed for interop with other general-purpose cryptographic tools or portability between platforms/languages/etc.
Tempel presumes that you'll do both encryption and decryption using Tempel, with Clojure on the JVM.
This limitation allows Tempel's API and codebase to be kept small and simple.
The security of a framework like Tempel depends on:
- Correct implementation
(1a.) Correct primitives
(1b.) Correct choice, use, and composition of primitives - Correct use
Unfortunately security depends on all of these being simultaneously correct.
In Tempel's case:
- (1a) is unlikely to be a problem since Tempel does not implement ("roll") its own cryptographic primitives. It instead uses the high-quality and extensively tested facilities provided natively by the JVM.
- (1b) is inevitably a risk whenever using a high-level framework like Tempel. My hope is that Tempel's simple protocols and formats are unlikely to be substantially incorrect and should be relatively easy to review/audit, and to keep updated with evolving best practices.
- (2) is inevitably a risk whenever using cryptography of any kind. My hope is that Tempel's high-level API and beginner-oriented documentation may actually help reduce the likelihood of mistakes here.
Ultimately you will need to assess for yourself:
- How valuable the security of your data is (/ how motivated an attacker might be)
- How complex your own needs are (custom protocols that may affect (2), etc.)
- What alternatives you may have (i.e. comparative risks)
Please be very careful evaluating Tempel and/or other cryptographic libraries/frameworks before use, especially new libraries/frameworks like Tempel!
Yes, unfortunately any time you encrypt data you inevitably introduce the risk of losing that data:
- Bugs and/or misuse could lead to the data being undecryptable.
- Accidental loss of decryption key/s could lead to the data being undecryptable.
It is critical to always:
- Test that data being encrypted can be successfully decrypted before discarding the original data.
- Ensure that appropriate backups are made and tested of the original data, and/or decryption keys.
Please err on the side of being overly cautious.
Tempel is a pretty thin wrapper over the JVM's native crypto facilities and shouldn't add significant overhead itself.
As for what performance to expect from the JVM's native crypto facilities - that depends a lot on your specific hardware and configuration (selected algorithms, work factors, etc.).
Both encryption and decryption can be slow and computationally expensive.
To get a realistic idea of performance, I'd recommend benchmarking in your own environment with your actual configuration and data.
The JVM offers flexible and well-implemented crypto facilities, but they tend to be low-level in nature and are often difficult to use correctly in practice.
Understanding what (not) to use and how to compose primitives into a coherent whole can require significant domain experience and/or research. Mistakes can be costly - difficult to correct, and potentially insecure.
Tempel uses the JVM's crypto API, but wraps it to:
- Provide an idiomatic Clojure experience
- Work at a higher level (see examples)
- Choose reasonable defaults, and highlight important choices
- Provide future-proof data formats with auto-updated algorithms and work factors over time
Tempel does not implement ("roll") its own cryptographic primitives, though it does necessarily implement its own higher-level protocols and data formats.
See here for more info about Tempel's security risks.