Re: Maybe It's Snake Oil All the Way Down
Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de> writes:
Using an explicit state machine helps to get code suitable for multiplexing within a single thread various connections using non-blocking I/O.
Is there some specific advantage here, or is it an academic exercise? Some quirk of supporting certain types of hardware like nCipher boxes that do async crypto/scatter-gather? I have a vague idea from discussions with some OpenSSL-engine developers that they had some requirement for supporting async hardware in non-threaded environments, but from hearing the complaints about how hard this ended up being I had the impression that this was a major rewrite rather than something the state-machine implementation had been specifically designed for (sorry, I don't have that much technical info, the discussions tended to devolve into griping sessions about how hard async crypto hardware was to work with, not helped by comments like "That's because you're taking the path of most resistance, just use threads" :-). I also don't know if that explains why, years before this was an issue, everyone was already treating SSL as a state machine problem. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Thu, Jun 05, 2003 at 10:11:45PM +1200, Peter Gutmann wrote:
Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de> writes:
Using an explicit state machine helps to get code suitable for multiplexing within a single thread various connections using non-blocking I/O.
Is there some specific advantage here, or is it an academic exercise? [...] I have a vague idea from discussions with some OpenSSL-engine developers that they had some requirement for supporting async hardware in non-threaded environments, [...] the discussions tended to devolve into griping sessions about how hard async crypto hardware was to work with, not helped by comments like "That's because you're taking the path of most resistance, just use threads" :-).
I don't mind working with threads, but there's a lot of software out there that uses single-threaded multiplexing, and adding SSL/TLS to such software becomes much easier if the SSL/TLS library supports this multiplexing paradigm. (Not that it would be impossible otherwise -- another option, for Unix anway, is to fork off a processes that handles a SSL/TLS connection and communicates with the main process via a pipe.) -- Bodo Mvller <moeller@cdc.informatik.tu-darmstadt.de> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036
Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de> writes:
Using an explicit state machine helps to get code suitable for multiplexing within a single thread various connections using non-blocking I/O.
Is there some specific advantage here, or is it an academic exercise? Some quirk of supporting certain types of hardware like nCipher boxes that do async crypto/scatter-gather? I've had to do this on environments where threads weren't a viable
pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: option. See, for instance, my paper from USENIX Security 2002. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/
participants (3)
-
Bodo Moeller -
Eric Rescorla -
pgut001＠cs.auckland.ac.nz