{"action":"created","issue":{"url":"https://api.github.com/repos/xaptum/xtt/issues/71","repository_url":"https://api.github.com/repos/xaptum/xtt","labels_url":"https://api.github.com/repos/xaptum/xtt/issues/71/labels{/name}","comments_url":"https://api.github.com/repos/xaptum/xtt/issues/71/comments","events_url":"https://api.github.com/repos/xaptum/xtt/issues/71/events","html_url":"https://github.com/xaptum/xtt/issues/71","id":368355010,"node_id":"MDU6SXNzdWUzNjgzNTUwMTA=","number":71,"title":"Crypto interface design (migrated from very old issue on original repository)","user":{"login":"zanebeckwith","id":4698352,"node_id":"MDQ6VXNlcjQ2OTgzNTI=","avatar_url":"https://avatars2.githubusercontent.com/u/4698352?v=4","gravatar_id":"","url":"https://api.github.com/users/zanebeckwith","html_url":"https://github.com/zanebeckwith","followers_url":"https://api.github.com/users/zanebeckwith/followers","following_url":"https://api.github.com/users/zanebeckwith/following{/other_user}","gists_url":"https://api.github.com/users/zanebeckwith/gists{/gist_id}","starred_url":"https://api.github.com/users/zanebeckwith/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zanebeckwith/subscriptions","organizations_url":"https://api.github.com/users/zanebeckwith/orgs","repos_url":"https://api.github.com/users/zanebeckwith/repos","events_url":"https://api.github.com/users/zanebeckwith/events{/privacy}","received_events_url":"https://api.github.com/users/zanebeckwith/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-10-09T19:10:20Z","updated_at":"2018-10-09T19:12:56Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Originally posted by @drbild over a year ago to the original repository.\r\n\r\nThough this is significantly out of date, I think the principles are still relevant, and wanted to retain the discussion.\r\n\r\n----------------------------------------------------------\r\n\r\nCrypto interface design\r\nThis is a brain-dump for now of my thoughts about the crypto interface design. We can refine it into a better description & discussion over time.\r\n\r\nImplications of Design Goals for XTT Implementation\r\nNo dynamic memory allocation required.\r\nSupport arbitrary implementations of the crypto primitives.\r\nAllow asynchronous crypto primitives for non-blocking use of HSMs.\r\nBe as performant (nearly) as a monolithic crypto lib.\r\nThese four goals alone pose some interesting incompatibilities. Consider the following possible implementations.\r\n\r\nShared header w/ arbitrary linked implementation\r\nNo dynamic memory allocation implies that all struct definitions must be visible to the calling code. The shared header thus implies that all implementations must share the same struct definitions. Of course, the different possible implementations for linking will use different underlying representations for primitives like keys. Thus, the representations must be translated at the interface boundary for every call. And that is not performant.\r\n\r\nThe translation could be done (at the cost of some cycles) were the data types always representing the same concept, e.g., different representations of an ed25519 key. The interface would define a common serialization format to translate to and from. But consider an implementation backed by an HSM. The private key would not actually be a key, but instead some opaque identifier for the key inside the HSM. Finding a clean, common representation seems difficult.\r\n\r\nAn alternative is for the interface to take pointers to opaque structs defined by the implementation. But this requires dynamic memory allocation, as those opaque structs would have to be allocated by the linked implementation code, where the full definition is known.\r\n\r\nShared header for functions, implementation-specific header for data types\r\nThis approach would solve the static allocation issue. The XTT library would have to be compiled against a specific implementation defining the structs. (The shared header defining the methods would just have forward declarations.)\r\n\r\nI'm leaning towards this approach currently. My general feeling is that the crypto implementation should be statically linked to the XTT library anyway (not like openSSL with a shared lib for the crypto). So this keep everything clean.\r\n\r\nPolymorphism - the Compile/Runtime, Global/Local matrix\r\nThe \"arbitrary implementation\" design goal is still ill-defined. Should the implementation be chosen at compile time or be configurable at run-time? Should it be common to the whole program or changeable for each XTT \"session\"?\r\n\r\nThe two approaches in the prior section are in the (compile-time, global) quadrant of the design space.\r\n\r\nSupporting runtime selection or local per-session selection of primitives seems to require either dynamic memory allocation or a shared/translatable representation of the data structures, which are non starters.\r\n\r\nProposed Approach\r\nXTT provides a shared header that forward declares the structs and methods used to access crypto primitives. The user is responsible for compiling XTT against an implementation that defines those structs and methods.\r\n\r\nWe provide two (or more) reference implementations that delegate to different libraries (say mbedTLS and wolfSSL).\r\n\r\nThese two implementations are in the (compile-time, global) quadrant above. They are applied globally to all XTT sessions within the program.\r\n\r\nAny user is free to provide their own implementation instead if they don't like our chosen point in the design space. Such an implementation could\r\n\r\nmix and match from various backends\r\nsupport linking-based selection of the backend by implementing a translation layer (like the first approach listed above)\r\nsupport runtime polymorphism at the cost of doing dynamic memory allocation from the library.\r\nThe point is that our interface doesn't preclude users from doing something more.\r\n\r\nThe one concession made to support this flexibility is the method for function dispatch. Rather than access the methods forward declared in the shared header directly by name, they are accessed via a vtable in the XTT context objects.\r\n\r\nImplementation\r\nI'll do a mock-up of this approach from the existing crypto lib to see how it looks and feels."},"comment":{"url":"https://api.github.com/repos/xaptum/xtt/issues/comments/428315209","html_url":"https://github.com/xaptum/xtt/issues/71#issuecomment-428315209","issue_url":"https://api.github.com/repos/xaptum/xtt/issues/71","id":428315209,"node_id":"MDEyOklzc3VlQ29tbWVudDQyODMxNTIwOQ==","user":{"login":"zanebeckwith","id":4698352,"node_id":"MDQ6VXNlcjQ2OTgzNTI=","avatar_url":"https://avatars2.githubusercontent.com/u/4698352?v=4","gravatar_id":"","url":"https://api.github.com/users/zanebeckwith","html_url":"https://github.com/zanebeckwith","followers_url":"https://api.github.com/users/zanebeckwith/followers","following_url":"https://api.github.com/users/zanebeckwith/following{/other_user}","gists_url":"https://api.github.com/users/zanebeckwith/gists{/gist_id}","starred_url":"https://api.github.com/users/zanebeckwith/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zanebeckwith/subscriptions","organizations_url":"https://api.github.com/users/zanebeckwith/orgs","repos_url":"https://api.github.com/users/zanebeckwith/repos","events_url":"https://api.github.com/users/zanebeckwith/events{/privacy}","received_events_url":"https://api.github.com/users/zanebeckwith/received_events","type":"User","site_admin":false},"created_at":"2018-10-09T19:12:56Z","updated_at":"2018-10-09T19:12:56Z","author_association":"CONTRIBUTOR","body":"Original comment from over a year ago:\r\n\r\n-------------------------------------------------------\r\n\r\nI don't think I quite see the use-case for the dynamic-polymorphism, or understand how that would work. What's the criterion for choosing a particular function pointer for a particular primitive? E.g. why have multiple choices for aes256-gcm?\r\n\r\nSupporting this, as you say, requires us to use function pointers, so does that mean the \"shared\" header would just typedef function pointers, rather than declaring functions? And we provide a setter function for the user to set which functions to use?"}}
{"actor":{"display_login":"zanebeckwith"}}