Hi Herbert,
On 8/26/20 9:19 AM, Herbert Xu wrote:
On Wed, Aug 26, 2020 at 08:57:17AM -0500, Denis Kenzior wrote:
I'm just waking up now, so I might seem dense, but for my education, can you
tell me why we need to set MSG_MORE when we issue just a single sendmsg
followed immediately by
Hi Herbert,
On 8/26/20 8:00 AM, Herbert Xu wrote:
On Wed, Aug 26, 2020 at 02:58:02PM +0200, Andrew Zaborowski wrote:
Running iwd's and ell's unit tests I can see that at least the
following algorithms give EINVAL errors:
ecb(aes)
cbc(aes)
ctr(aes)
The first one fails in recv() and only for so
Hi Eric,
On 06/07/2019 05:40 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 04:54:04PM -0500, Denis Kenzior wrote:
Hi Eric,
On 06/07/2019 04:41 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 04:28:59PM -0500, Denis Kenzior wrote:
Hi Eric,
On 06/07/2019 04:15 PM, Eric Biggers wrote:
On
Hi Eric,
On 06/07/2019 04:41 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 04:28:59PM -0500, Denis Kenzior wrote:
Hi Eric,
On 06/07/2019 04:15 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 03:45:45PM -0500, Denis Kenzior wrote:
Hi Ard,
Ah ok, good to know. That does imply that the
Hi Eric,
On 06/07/2019 04:15 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 03:45:45PM -0500, Denis Kenzior wrote:
Hi Ard,
Ah ok, good to know. That does imply that the driver is not entirely
broken, which is good news I suppose.
Not entirely, but we did have to resort to using multiple
Hi Ard,
Ah ok, good to know. That does imply that the driver is not entirely
broken, which is good news I suppose.
Not entirely, but we did have to resort to using multiple sockets,
otherwise parallel encrypt/decrypt operations on the socket would result
in invalid behavior. Probably due
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
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?
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 a
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
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
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
Hi Tudor,
On 02/28/2018 10:52 AM, Tudor Ambarus wrote:
The ECDH private keys are expected to be encoded with the ecdh
helpers from kernel.
Use the ecdh helpers to check if the key is valid. If valid,
allocate a tfm and set the private key. There is a one-to-one
binding between the private key a
. This
would imply that KPP supports encryption, decryption, sign, verify. Do
you mean 0x10 here?
+#define KEYCTL_SUPPORTS_COMPUTE_SS 0x10
+
And 0x20 here?
#endif /* _LINUX_KEYCTL_H */
Otherwise this looks good to me. Feel free to add:
Reviewed-by: Denis Kenzior
Regards,
-Denis
Hi Stephan,
>>
This brings me to another proposal for read buffer sizing: AF_ALG akcipher
can guarantee that partial reads (where the read buffer is shorter than
the output of the crypto op) will work using the same semantics as
SOCK_DGRAM/SOCK_SEQPACKET. With those sockets, as much data as will
Hi Herbert,
On 06/22/2016 09:20 AM, Herbert Xu wrote:
On Wed, Jun 22, 2016 at 09:19:16AM -0500, Denis Kenzior wrote:
Just to clarify, we use this from userspace. So we _already_ depend
on this functionality. Please keep the hash and non-hash versions
of pkcs1pad available.
How can you be
Hi Herbert,
On 06/22/2016 09:02 AM, Herbert Xu wrote:
On Wed, Jun 22, 2016 at 03:20:51PM +0200, Andrzej Zaborowski wrote:
We use pkcs1pad with AF_ALG to implement lightweight TLS. TLS
versions < 1.2 use a non-standard hash so we'd have to move the PKCS#1
padding back to userspace if this is c
17 matches
Mail list logo
