From: ol.sc@web.de   
      
   Hi Ewen,   
      
   > [...] but if it was instead of an Uthernet card, then we would need a new   
   > Link Layer which I could help with...   
      
   Network devices with hardware encryption support to be used for SSL/TLS all   
   have this issue:   
      
   A "modern" (e.g. Linux) program using SSL does so in user space, not in the   
   OS kernel. But the device comes with an OS driver. Therefore those devices   
   have proprietary (usually very complex) interfaces to interact with the   
   user space program. That interaction is encapsulated in patched versions of   
   popular SSL libraries.   
      
   So for Marinetti to make use of the encryption features of such a device,   
   it would need to   
   a) support that complex interaction. E.g. typically, the very expensive   
   asymmetric SSL handshake isn't done by the device at all. Rather it "only"   
   does the symmetric stream encryption.   
   b) supply an API to GS/OS program allowing to declare that SSL is desired.   
      
   From my perspective, a device targeting low end IoT scenarios would be   
   _way_ more suited to "our" use case.   
      
   However, such a device would pose its own challenges for GS/OS. Such   
   devices allow to open - typically one - TCP connection to a hostname. And   
   that connection can optionally be a secure one (aka SSL/TLS). But that   
   implies that the whole TCP/IP stack is implemented on the device, not on   
   the "host".   
      
   So such a device can't be used _with_ Marinetti. It can only be used   
   _instead_of_ Marinetti. Maybe one could create a Marinetti-compatible   
   interface for such a device allowing some/many/most Marinetti programs to   
   work with it instead of Marinetti.   
      
   Regards,   
   Oliver   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)