3 ms·
Yes you can? // lib.h struct SecureString { uint8_t *content; size_t len; } bool secure_str_eq(l *SecureString, r *SecureString) {
by 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 agoOk, now how do you provide a SecureUserCreatedStructuredData type?
- halpmeh 4y agoSerialize SecureUserCreatedStructuredData into an array of SecureString (or SecureInt, etc).
- joshuamorton 4y agoWhat 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.