On Sunday, May 27, 2018 2:33:33 PM CEST Theodore Y. Ts'o wrote:
> On Sun, May 27, 2018 at 01:22:05PM +0200, Rafael J. Wysocki wrote:
> > Again, the PBKDF2 user would be hibernation. It could either take a key
> > from
> > user space, which would require a key-generating user-space component to be
On Sun, May 27, 2018 at 01:22:05PM +0200, Rafael J. Wysocki wrote:
> Again, the PBKDF2 user would be hibernation. It could either take a key from
> user space, which would require a key-generating user-space component to be
> present in the initramfs (I guess no issue for a regular distro, but I c
On Saturday, May 26, 2018 7:12:36 AM CEST Herbert Xu wrote:
> On Tue, May 22, 2018 at 11:00:40AM +0800, Yu Chen wrote:
> > Hi all,
> > The request is that, we'd like to generate a symmetric key derived from
> > user provided passphase(not rely on any third-party library). May I know if
> > there is
On Sat, May 26, 2018 at 03:36:37PM +0200, Stephan Mueller wrote:
> - security related code should be vetted (which arguably is the case when the
> discussed PBKDF is part of the kernel)
> >
> > If he/she were to add their own userland code then he would surely be
> > criticized for rolling his ow
Am Samstag, 26. Mai 2018, 14:17:11 CEST schrieb Jeffrey Walton:
Hi Jeffrey,
> On Thu, May 24, 2018 at 5:11 AM, Stephan Mueller
wrote:
> > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
> >
> > Hi Rafael,
> >
> >> So the problem is that Yu would like to use this for hibe
On Thu, May 24, 2018 at 5:11 AM, Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
>
> Hi Rafael,
>
>> So the problem is that Yu would like to use this for hibernation encryption
>> done entirely in the kernel.
>
> But why do you need to perform PBKDF i
On Tue, May 22, 2018 at 11:00:40AM +0800, Yu Chen wrote:
> Hi all,
> The request is that, we'd like to generate a symmetric key derived from
> user provided passphase(not rely on any third-party library). May I know if
> there is a PBKDF2(Password-Based Key Derivation Function 2) support in the
> k
Hi Denis,
On Fri, May 25, 2018 at 09:48:36AM -0500, Denis Kenzior wrote:
> Hi Eric,
>
> > The solution to the "too many system calls" problem is trivial: just do
> > SHA-512
> > in userspace. It's just math; you don't need a system call, any more than
> > you
> > would call sys_add(1, 1) to co
Hi Eric,
The solution to the "too many system calls" problem is trivial: just do SHA-512
in userspace. It's just math; you don't need a system call, any more than you
would call sys_add(1, 1) to compute 1 + 1. The CPU instructions that can
accelerate SHA-512, such as AVX and ARM CE, are availa
On Fri, May 25, 2018 at 12:07:06PM +0200, Tomas Mraz wrote:
>
> Because having millions of copies of SHA1, MD5, and SHA2 and in
> millions of applications is the best thing.
>
> Now that's something I would call laziness - just copy the code and do
> not care about doing the proper decision w
On Thu, 2018-05-24 at 20:42 -0400, Theodore Y. Ts'o wrote:
> On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote:
> >
> > But seriously, how is it a fault of the 'random person on the
> > mailing list'
> > that AF_ALG exists and is being used for its (seemingly intended)
> > purpose?
> >
Hi Denis,
On Thu, May 24, 2018 at 07:56:50PM -0500, Denis Kenzior wrote:
> Hi Ted,
>
> > > I'm not really here to criticize or judge the past. AF_ALG exists now. It
> > > is being used. Can we just make it better? Or are we going to whinge at
> > > every user that tries to use (and improve) ke
Hi Ted,
I'm not really here to criticize or judge the past. AF_ALG exists now. It
is being used. Can we just make it better? Or are we going to whinge at
every user that tries to use (and improve) kernel features that (some)
people disagree with because it can 'compromise' kernel security?
One more thought about why userspace using AF_ALG is a bad idea ---
there is no guarantee that all kernels will have all of the crypto
algorithms you need built into the kernel. People who build custom
kernels very often only include those kernel modules they need. So by
default I don't normally
On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote:
>
> But seriously, how is it a fault of the 'random person on the mailing list'
> that AF_ALG exists and is being used for its (seemingly intended) purpose?
>
> I'm not really here to criticize or judge the past. AF_ALG exists now. I
Hi Ted,
On 05/24/2018 06:25 PM, Theodore Y. Ts'o wrote:
On Thu, May 24, 2018 at 05:08:41PM -0500, Denis Kenzior wrote:
Actually for the use case we have, speed is something pretty low on the
priority list; not having to deal with userspace crypto library dependencies
was a goal in and of itself
On Thu, May 24, 2018 at 05:08:41PM -0500, Denis Kenzior wrote:
> Actually for the use case we have, speed is something pretty low on the
> priority list; not having to deal with userspace crypto library dependencies
> was a goal in and of itself. Each one has its own issues and you can never
> sup
Hi Ted,
On 05/24/2018 04:05 PM, Theodore Y. Ts'o wrote:
Has anyone actually done the experiment and verified that it was in
fact a win to use AF_ALG on at least _some_ platform? What about the
common cast for most platforms, even those that had some kind of
hardware accleration that could only
On Thu, May 24, 2018 at 12:11:35PM -0500, Denis Kenzior wrote:
>
> Well, I'm not sure where the laziness comment is coming from. We have at
> least two user-space implementations that implement PBKDF on top of AF_ALG.
> But a typical invocation of PBKDF runs a couple of thousand iterations.
> Tha
Hi Eric,
No, we don't add random code to the kernel just because people are lazy. IMO it
was a mistake that AF_ALG allows access to software crypto implementations by
default (as opposed to just hardware crypto devices), but it's not an excuse to
I understand, but my point is, AF_ALG is out t
On Thu, May 24, 2018 at 09:36:15AM -0500, Denis Kenzior wrote:
> Hi Stephan,
>
> On 05/24/2018 12:57 AM, Stephan Mueller wrote:
> > Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:
> >
> > Hi Eric,
> >
> > >
> > > "Not having to rely on any third-party library" is not an excuse
Hi Stephan,
On 05/24/2018 12:57 AM, Stephan Mueller wrote:
Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:
Hi Eric,
"Not having to rely on any third-party library" is not an excuse to add
random code to the kernel, which runs in a privileged context. Please do
PBKDF2 in use
On Thursday, May 24, 2018 11:36:04 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki:
>
> Hi Rafael,
>
> > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote:
> > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysoc
Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki:
Hi Rafael,
> On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote:
> > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
> >
> > Hi Rafael,
>
> Hi Stephan,
>
> > > So the problem is that Yu wo
On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
>
> Hi Rafael,
Hi Stephan,
> > So the problem is that Yu would like to use this for hibernation encryption
> > done entirely in the kernel.
>
> But why do yo
Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki:
Hi Rafael,
> So the problem is that Yu would like to use this for hibernation encryption
> done entirely in the kernel.
But why do you need to perform PBKDF in kernel space?
If you retain the password information in the kerne
On Thursday, May 24, 2018 7:57:37 AM CEST Stephan Mueller wrote:
> Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:
>
> Hi Eric,
>
> >
> > "Not having to rely on any third-party library" is not an excuse to add
> > random code to the kernel, which runs in a privileged context. P
Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:
Hi Eric,
>
> "Not having to rely on any third-party library" is not an excuse to add
> random code to the kernel, which runs in a privileged context. Please do
> PBKDF2 in userspace instead.
I second that. Besides, if you really
Hi Yu,
On Thu, May 24, 2018 at 10:26:12AM +0800, Yu Chen wrote:
> Hi Stephan,
> thanks for your reply,
> On Wed, May 23, 2018 at 1:43 AM Stephan Mueller wrote:
>
> > Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen:
>
> > Hi Yu,
>
> > > Hi all,
> > > The request is that, we'd like to g
Hi Stephan,
thanks for your reply,
On Wed, May 23, 2018 at 1:43 AM Stephan Mueller wrote:
> Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen:
> Hi Yu,
> > Hi all,
> > The request is that, we'd like to generate a symmetric key derived from
> > user provided passphase(not rely on any thir
Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen:
Hi Yu,
> Hi all,
> The request is that, we'd like to generate a symmetric key derived from
> user provided passphase(not rely on any third-party library). May I know if
> there is a PBKDF2(Password-Based Key Derivation Function 2) support
Hi all,
The request is that, we'd like to generate a symmetric key derived from
user provided passphase(not rely on any third-party library). May I know if
there is a PBKDF2(Password-Based Key Derivation Function 2) support in the
kernel? (https://tools.ietf.org/html/rfc2898#5.2)
We have hmac sha1
32 matches
Mail list logo
