Some users insist on using only cryptography officially sanctioned by their favorite standards body, such as the NIST FIPS-140; notary should at least not make this impossible by design. The following areas may be relevant:
Cryptosystem design: Notary is currently using pretty vanilla signatures and hashes, and does no key derivation or any other non-trivial combinations of algorithms, so this should be fine.
Algorithm choice: The hard-coded crypto algorithms need to be from the approved set, and the non-hardcoded ones need to include at least one approved algorithm. At least based on a 5-minute look the current major choices (ECDSA with P-256 and SHA-256) are fine with FIPS-140.
Crypto implementation: The specific implementation of the algorithms needs to be validated by an independent lab. In practice, this would probably mean using a major already validated library, perhaps OpenSSL, either directly through some bindings, or indirectly by using a golang crypto implementation backed by such a library.
(This is mostly a placeholder for more detailed research in the future.)
Based on NSA advice we are reconsidering our use of P-256 and should add SHA-384 or 512 in addition to current use of SHA-256 (will file a separate issue for SHA update)
Some users insist on using only cryptography officially sanctioned by their favorite standards body, such as the NIST FIPS-140; notary should at least not make this impossible by design. The following areas may be relevant:
crypto
implementation backed by such a library.(This is mostly a placeholder for more detailed research in the future.)