Bodo Moeller wrote:
> > ... I have the feeling that much of the kludginess of
> > the OpenSSL code is there to handle the fact that input arrives not
> > as whole SSL Record Layer units, but in dribs and drabs, and lots of
> > effort is expended in tracking where you are, and being able to resume
On Thu, Nov 16, 2000 at 11:16:24PM -0800, Dan Kegel wrote:
>>> My API proposal was meant to generate discussion. I realize it's not an
>>> especially practical direction to move OpenSSL in. Does the idea of
>>> an event-driven SSL API appeal to anybody, at least in the abstract?
>> Well, we ne
On Tue, Nov 14, 2000 at 07:28:03PM -0800, Dan Kegel wrote:
>> It should be possible to implement something close to what you
>> describe at http://www.kegel.com/ssl/api.html> on top of the
>> current SSL API with new SSL_get_error return values addeed, using
>> either a BIO pair or memory BIOs.
Geoff Thorpe wrote:
> Well the sample size is not immense, but internally hardware usually
> functions in an async manner, and typically the APIs/SDKs are such that
> you can use the stuff in that way. I think you'll find if you delve into
> the vendor_defn/ headers in the engine stuff, and look a
Hey there,
On Wed, 15 Nov 2000, Dan Kegel wrote:
> Say, what do the existing crypto hardware devices provide in the
> way of interfaces and synchronization? Where's the best place to find out
> that kind of info? (The engine branch of OpenSSL will help, but it
> might not use all the hooks
At 09:21 PM 11/15/00 -0800, Dan wrote:
>My API proposal was meant to generate discussion. I realize it's not an
>especially practical direction to move OpenSSL in. Does the idea of
>an event-driven SSL API appeal to anybody, at least in the abstract?
Yes.
Geoff Thorpe wrote:
> On Tue, 14 Nov 2000, Dan Kegel wrote:
> > I don't think we need nonblocking crypto; it would be enough to be able
> > to shunt the crypto off into another thread. That's what my API proposal
> > was about.
>
> I think that misses the entire point of why a form of async publ
On Tue, 14 Nov 2000, Dan Kegel wrote:
> I don't think we need nonblocking crypto; it would be enough to be able
> to shunt the crypto off into another thread. That's what my API proposal
> was about.
I think that misses the entire point of why a form of async public-key
crypto might be advantag
> I don't think we need nonblocking crypto; it would be enough to be able
> to shunt the crypto off into another thread. That's what my API proposal
> was about.
Insufficient for hardware crypto devices.
__
OpenSSL Project
Bodo Moeller wrote:
> On Mon, Nov 13, 2000 at 07:16:39PM -0800, Dan Kegel wrote:
> > Nonblocking network I/O is tricky with the current API, but doable.
> > I've got working code for that, and there are good examples now.
> > Nonblocking crypto is another matter; it would be a real pain, and
> > t
On Mon, Nov 13, 2000 at 07:16:39PM -0800, Dan Kegel wrote:
> Nonblocking network I/O is tricky with the current API, but doable.
> I've got working code for that, and there are good examples now.
> Nonblocking crypto is another matter; it would be a real pain, and
> there are no examples showi
Richard Levitte - VMS Whacker wrote:
> From: Dan Kegel <[EMAIL PROTECTED]>
>
> dank> BIO's should have been a well-separated layer, not an integral
> dank> part of OpenSSL.
>
> I'm not sure I understand that argument. BIO's *are* separate, in
> their own "module", if you wish to express it that
12 matches
Mail list logo
