| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
| |
Clarify the division between internal and external modules in the source
by consolidating all internal modules except Data.Digest.Internal into a
flatter BTLS directory.
|
| |
|
| |
|
|
|
|
| |
Implement the `extract` phase of HKDF.
|
|
|
|
|
|
|
|
|
|
| |
Instead of using `-Weverything` and turning warnings off as they become
problematic, enable `-Werror` and turn on a specific set of warnings
judged to have high signal-to-noise ratio. Fix up all instances of those
warnings in the code.
These warnings are all available in GHC 8.0.1, which is the default in
the current Debian (Debian 9).
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I don’t always like the output hindent gives, so reformat the project
to be a bit closer to what you see in published Haskell books and the
like.
|
| |
|
| |
|
|
|
|
|
|
|
| |
It’s clear at this point that this system is going to get large enough
that a two-layer implementation is warranted. `Internal` will contain
low-level bindings to BoringSSL; other modules will export an idiomatic
interface on top of them.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Let the computer figure out its own types for most foreign imports.
Continue using the vanilla FFI for finalizers, though, as that’s the
easiest way to deal with function pointers.
Reuse the build hook from gtk2hs-buildtools to work around Cabal’s
inability to topologically sort .chs dependencies
(https://github.com/haskell/cabal/issues/1906).
|
| |
|
| |
|
|
|
|
|
|
|
| |
Eliminate the functional interface for hashing. Hashing now occurs
exclusively through the `hash` function, which accepts a
`Data.Digest.Algorithm`. This makes btls somewhat less extensible, but
it’s the most elegant way to support HMACs.
|
|
|
|
|
|
|
| |
Use the finalizer techniques demonstrated in
4e56c79b907da4a4654e5278bdcf94b08480a426 to safely allocate `EVP_MD_CTX`
on the Haskell heap. This allows us to return to the high-level EVP API,
eliminating much boilerplate code.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Switch SHA-2 API to use lazy ByteStrings rather than strict. Lazy
ByteStrings make the hash function compatible with streaming I/O
patterns; users no longer need to preload all the data they wish to hash
into RAM.
|
|
|
|
|
|
| |
Implement a wrapper for `OPENSSL_cleanse` and use it to securely erase
hash buffers. This matches the behavior of BoringSSL’s all-in-one hash
functions (`SHA256`, `SHA512`, etc.) and memory allocation subsystem.
|
|
|
|
|
|
|
|
|
| |
Rework the SHA-2 implementation to use the low-level sha.h interface
rather than the higher-level evp.h. This allows us to preallocate all
the data structures, eliminating BoringSSL cleanup functions. As a
result, we can implement hashing under `unsafeLocalState` (a.k.a.
`unsafeDupablePerformIO`) instead of `unsafePerformIO`, which should
improve performance in multithreaded programs.
|
|
So far, btls provides SHA-224, SHA-256, SHA-384, and SHA-512 algorithms.
To do that, I
- vendor BoringSSL and create a custom `Setup.hs` to build it,
- wrap a number of functions and values from BoringSSL's EVP
subsystem, and
- implement the four SHA-2 algorithms using the wrapped routines.
I provide conformance tests incorporating the official NIST example
vectors and the vectors used in the Go SHA-2 test suite. The tests also
use SmallCheck to compare btls’s SHA-2 implementations with those
provided by the system’s Coreutils and openssl(1) installations.
|