3 ms·

Why is that odd? You could provide a typed API in other languages that leverages a suite of different side-channel proof algorithms. In order to provide such an

Why is that odd? You could provide a typed API in other languages that leverages a suite of different side-channel proof algorithms. In order to provide such an API, you need a portable language compatible with the C calling convention for FFI support in other languages. The only language that meets such criteria is C.

joshuamorton 4y ago
You can't provide an API that gives the security features they want in c. The core feature here is a generic secret type. In c that's a void*, defeating the purpose of the typed, safe, API.
- halpmeh 4y ago
  Yes you can? // lib.h struct SecureString { uint8_t *content; size_t len; } bool secure_str_eq(l *SecureString, r *SecureString) { // some constant-time algorithm } SecureString *new_secur_string() { struct SecureString *s = malloc(sizeof(struct SecureString)); // initialize s return s; } And then in go, for instance, you would do something like this: // #include "lib.h" import "C" type SecureString struct { ptr *C.struct_SecureString } func NewSecureString() *SecureString { return &SecureString { ptr: C.new_secure_string(), } } func (s *SecureString) Eq(other SecureString*) bool { return C.secure_str_eq(h.ptr, other.ptr) }
  - TylerE 4y ago
    Ok, now how do you provide a SecureUserCreatedStructuredData type?
    - halpmeh 4y ago
      Serialize SecureUserCreatedStructuredData into an array of SecureString (or SecureInt, etc).
      - joshuamorton 4y ago
        What if I want my application to be performant? There's no value in c abi compatibility if the code internally costs a serialization round trip all the time. May as well just use rusts ffi at that point, it'll be faster! Also how do you even operate on a SecureUserCreatedStructuredData that is serialized into a SecureString or SecureBytes? Does my function that operates on a SecureUserCreatedStructureData take in a SecureString, which is documented as needing to be deserializable to a SecureUserCreatedStructureData? If so, that's just a secure void*, with all the problems void* has, and slower.

joshuamorton 4y ago

You can't provide an API that gives the security features they want in c. The core feature here is a generic secret type. In c that's a void*, defeating the purpose of the typed, safe, API.

halpmeh 4y ago
Yes you can? // lib.h struct SecureString { uint8_t *content; size_t len; } bool secure_str_eq(l *SecureString, r *SecureString) { // some constant-time algorithm } SecureString *new_secur_string() { struct SecureString *s = malloc(sizeof(struct SecureString)); // initialize s return s; } And then in go, for instance, you would do something like this: // #include "lib.h" import "C" type SecureString struct { ptr *C.struct_SecureString } func NewSecureString() *SecureString { return &SecureString { ptr: C.new_secure_string(), } } func (s *SecureString) Eq(other SecureString*) bool { return C.secure_str_eq(h.ptr, other.ptr) }
- TylerE 4y ago
  Ok, now how do you provide a SecureUserCreatedStructuredData type?
  - halpmeh 4y ago
    Serialize SecureUserCreatedStructuredData into an array of SecureString (or SecureInt, etc).
    - joshuamorton 4y ago
      What if I want my application to be performant? There's no value in c abi compatibility if the code internally costs a serialization round trip all the time. May as well just use rusts ffi at that point, it'll be faster! Also how do you even operate on a SecureUserCreatedStructuredData that is serialized into a SecureString or SecureBytes? Does my function that operates on a SecureUserCreatedStructureData take in a SecureString, which is documented as needing to be deserializable to a SecureUserCreatedStructureData? If so, that's just a secure void*, with all the problems void* has, and slower.