4 ms·

Absolutely, we wrote our own post-quantum crypto engine that has no side-channel attacks and has little to no performance overhead... Just kidding! We do not

Absolutely, we wrote our own post-quantum crypto engine that has no side-channel attacks and has little to no performance overhead... Just kidding! We do not write any of our own crypto. We use common open source libraries like libsodium, WolfSSL, OpenSSL, etc. under the hood. We provide binary versions of our library linked against the appropriate libraries for the customer, or customers can build their own combination of our library+crypto dependencies from source. Sometimes we help customers get the compile options right to take advantage of, say, NEON instructions to optimize for an ARM target, but that's about the extent in terms of touching the actual crypto library.

mediocrejoker 8y ago
What does it mean to say that something has no side channel attacks? Do you mean no known side channel attacks? If so, doesn't any product with regular security updates meet this criteria? Or have you somehow ruled out the possibility of side channel attacks (which sounds impossible to me, but I am not an expert)
- hojothum 8y ago
  Sorry, I made a bad joke above. I'm guessing there are almost certainly side-channel attacks (discovered or not) in most crypto libraries. How easily they're exploited is another topic. We don't believe we need to build more cryptography engines. We just think we need to make the existing crypto libraries easier to use in conjunction with PKI, vulnerability monitoring, ease of patching, and especially in the context of documentation and testing in the eyes of the FDA.
tptacek 8y ago
That's good to hear. Presumably you're doing encryption at rest in addition to TLS. Can you talk about the constructions you've come up with to do that?
- hojothum 8y ago
  Admittedly, most of our focus (on the crypto end) has been on simplifying the key provisioning/management process, establishing secure sockets, and signing and verifying data. Our protocol does allow for storing a source ID and additional data with encrypted message data as a single serialized set of binary data to be written to disk or database. When this data is deserialized we can use the source ID to locate the key and then recover the original data with the AD and encrypted data. Underneath, calls would be made to the open source crypto lib yielding, for example, data encrypted via ChaCha20 stream cipher with Poly1305 MAC authentication. Also, our platform generates a provisioning configuration that tells the device to generate a dedicated set of keys for the purpose of encrypting data at rest. Those keys would not be used for any other signing or socket security operations. In general, if the target hardware can support it, we create dedicated keys for each type of data security operation (read multiple RPCs sending different types of data like log data, command-control data, images). We think this is especially important for encrypting data with LTKs since there have been cases where encrypting with a secret key has resulted in secret key leakage.

mediocrejoker 8y ago

What does it mean to say that something has no side channel attacks? Do you mean no known side channel attacks? If so, doesn't any product with regular security updates meet this criteria? Or have you somehow ruled out the possibility of side channel attacks (which sounds impossible to me, but I am not an expert)

hojothum 8y ago
Sorry, I made a bad joke above. I'm guessing there are almost certainly side-channel attacks (discovered or not) in most crypto libraries. How easily they're exploited is another topic. We don't believe we need to build more cryptography engines. We just think we need to make the existing crypto libraries easier to use in conjunction with PKI, vulnerability monitoring, ease of patching, and especially in the context of documentation and testing in the eyes of the FDA.

tptacek 8y ago

That's good to hear. Presumably you're doing encryption at rest in addition to TLS. Can you talk about the constructions you've come up with to do that?

hojothum 8y ago
Admittedly, most of our focus (on the crypto end) has been on simplifying the key provisioning/management process, establishing secure sockets, and signing and verifying data. Our protocol does allow for storing a source ID and additional data with encrypted message data as a single serialized set of binary data to be written to disk or database. When this data is deserialized we can use the source ID to locate the key and then recover the original data with the AD and encrypted data. Underneath, calls would be made to the open source crypto lib yielding, for example, data encrypted via ChaCha20 stream cipher with Poly1305 MAC authentication. Also, our platform generates a provisioning configuration that tells the device to generate a dedicated set of keys for the purpose of encrypting data at rest. Those keys would not be used for any other signing or socket security operations. In general, if the target hardware can support it, we create dedicated keys for each type of data security operation (read multiple RPCs sending different types of data like log data, command-control data, images). We think this is especially important for encrypting data with LTKs since there have been cases where encrypting with a secret key has resulted in secret key leakage.