On Tue, Dec 18, 2018 at 08:53:54AM -0500, Thor Lancelot Simon wrote:
> They did _not_ cause measureable performance problems of any kind, and
> though it is theoretically possible to do this sort of thing via a
> tightly-protected userspace helper process, I prototyped that too and
> it gets very
On Fri, Dec 14, 2018 at 03:19:45PM +0100, Joerg Sonnenberger wrote:
> On Thu, Dec 13, 2018 at 11:07:23PM +0900, Ryota Ozaki wrote:
> > On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger wrote:
> > >
> > > On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote:
> > > > Before that, I want to
>>> Asymmetrical cryptography is slow and complex.
>> Didn't that ship sail long ago? I recall seeing people talking
>> about putting entire languages into the kernel, in some cases even
>> including jitters. Much as I dislike this, I find that far more "no
>> way in hell is that going into _my_
> On Dec 14, 2018, at 2:16 PM, Joerg Sonnenberger wrote:
>
> On Fri, Dec 14, 2018 at 01:00:25PM -0500, Mouse wrote:
> ...
>> I also disagree that asymmetric crypto is necessarily all that complex.
>> Some asymmetric crypto algorithms require nothing more complex than
>> large-number
On Fri, Dec 14, 2018 at 01:00:25PM -0500, Mouse wrote:
> >>> [...] I have serious concerns for doing asymmetric cryptography in
> >>> the kernel [...]
> >> Can you clarify the concerns?
> > Asymmetrical cryptography is slow and complex. [...] The
> > implementation is non-trivial [...]
>
>
>>> [...] I have serious concerns for doing asymmetric cryptography in
>>> the kernel [...]
>> Can you clarify the concerns?
> Asymmetrical cryptography is slow and complex. [...] The
> implementation is non-trivial [...]
Didn't that ship sail long ago? I recall seeing people talking about
> On Dec 14, 2018, at 6:19 AM, Joerg Sonnenberger wrote:
> Asymmetrical cryptography is slow and complex. On many architectures,
> the kernel will only be able to use slower non-SIMD implementations. ECC
> still easily requires 10k cycles per operation. The implementation is
> non-trivial in
On Thu, Dec 13, 2018 at 11:07:23PM +0900, Ryota Ozaki wrote:
> On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger wrote:
> >
> > On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote:
> > > Before that, I want to ask about how to import cryptography
> > > libraries needed tor the
On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger wrote:
>
> On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote:
> > Before that, I want to ask about how to import cryptography
> > libraries needed tor the implementation. The libraries are
> > libb2[1] and libsodium[2]: the former is
On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote:
> Before that, I want to ask about how to import cryptography
> libraries needed tor the implementation. The libraries are
> libb2[1] and libsodium[2]: the former is for blake2s and
> the latter is for curve25519 and
On Thu, Dec 13, 2018 at 2:12 AM Greg Troxel wrote:
>
> m...@netbsd.org writes:
>
> > I don't expect there to be any problems with the ISC license. It's the
> > preferred license for OpenBSD and we use a lot of their code (it's
> > everywhere in sys/dev/)
>
> Agreed that the license is ok.
>
> >
m...@netbsd.org writes:
> I don't expect there to be any problems with the ISC license. It's the
> preferred license for OpenBSD and we use a lot of their code (it's
> everywhere in sys/dev/)
Agreed that the license is ok.
> external, as I understand it, means "please upstream your changes, and
I don't expect there to be any problems with the ISC license. It's the
preferred license for OpenBSD and we use a lot of their code (it's
everywhere in sys/dev/)
external, as I understand it, means "please upstream your changes, and
avoid unnecessary local changes".
13 matches
Mail list logo
