Am Freitag, dem 09.04.2021 um 10:11 +0800 schrieb Hangbin Liu:
> On Thu, Apr 08, 2021 at 08:11:34AM -0700, Eric Biggers wrote:
> > On Thu, Apr 08, 2021 at 07:58:08PM +0800, Hangbin Liu wrote:
> > > On Thu, Apr 08, 2021 at 09:06:52AM +0800, Hangbin Liu wrote:
> > > > > Also, couldn't you just consid
ed, either at compile or via proc, it can not be disabled.
> Redacting secret is a FIPS 140-2 requirement.
>
> Cc: Stephan Mueller
> Signed-off-by: Antony Antony
> ---
> Documentation/networking/xfrm_sysctl.rst | 7 +++
> include/net/netns/xfrm.h | 1 +
> net/
Am Mittwoch, 17. Januar 2018, 20:22:13 CET schrieb Christoph Hellwig:
Hi Christoph,
> On Sun, Jan 14, 2018 at 09:01:00AM +0100, Stephan Müller wrote:
> > The syscall io_submit sends data to the kernel and invokes the respective
> > handler function in the kernel such as the recvmsg handler. What
e enough for use
> in real world applications.
>
> Signed-off-by: Björn Esser
Considering NR_FILE defining the default maximum number of file descriptors,
at max 335 MB of RAM (32 bit) or 670 MB (64 bit) could be allocated which I
would assume to be ok in current systems.
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Donnerstag, 7. Dezember 2017, 16:08:04 CET schrieb Atul Gupta:
Hi Atul,
> > As far as I see, the key is part of the skb (via kctx). This skb is
> > released after being processed. The release calls kfree_skb which does
> > not zeroize the key. Wouldn't it make sense to clear the memory of the
Am Donnerstag, 7. Dezember 2017, 15:21:03 CET schrieb Atul Gupta:
Hi Atul,
>
> memzero_explicit(key)?
> [Atul] may not be required as entire info of size keylen and AEAD_H_SIZE is
> copied onto kctx->key. Key data is received from user, while ghash is
> memset and locally generated
Sure, but wo
Am Dienstag, 5. Dezember 2017, 12:40:29 CET schrieb Atul Gupta:
Hi Atul,
> program the tx and rx key on chip.
>
> Signed-off-by: Atul Gupta
> ---
> drivers/crypto/chelsio/chtls/chtls_hw.c | 394
> 1 file changed, 394 insertions(+)
> create mode 100644 drivers/c
Am Dienstag, 24. November 2015, 12:54:07 schrieb Phil Sutter:
Hi Phil,
>
>There "still" are dedicated crypto engines out there which need a driver
>to be accessed, so using them from userspace is not as simple as with
>padlock or AESNI. This was the reasoning behind the various cryptodev
>implemen
Am Dienstag, 24. November 2015, 12:20:00 schrieb Hannes Frederic Sowa:
Hi Hannes,
>
>You could also keep the secret in a master process and talk to that via
>ipc.
I could not agree more.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
Am Dienstag, 24. November 2015, 18:34:55 schrieb Herbert Xu:
Hi Herbert,
>On Mon, Nov 23, 2015 at 09:43:02AM -0800, Dave Watson wrote:
>> Userspace crypto interface for TLS. Currently supports gcm(aes) 128bit
>> only, however the interface is the same as the rest of the SOCK_ALG
>> interface, so
Am Montag, 1. Juni 2015, 16:35:26 schrieb Johannes Berg:
Hi Johannes,
>
>IOW, I think something like this would make sense:
>
That looks definitely cleaner :-)
Though, my main concern was just to ensure that the aad length value is not
zero.
Ciao
Stephan
--
To unsubscribe from this list: sen
Am Montag, 1. Juni 2015, 15:42:41 schrieb Johannes Berg:
Hi Johannes,
>On Mon, 2015-06-01 at 15:21 +0200, Stephan Mueller wrote:
>> Just a short question on ieee80211_aes_ccm_encrypt,
>> ieee80211_aes_ccm_decrypt, ieee80211_aes_gcm_encrypt,
>> ieee80211_aes_gcm_decrypt, ie
Am Donnerstag, 21. Mai 2015, 13:20:49 schrieb Johannes Berg:
Hi Johannes,
> On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
> > This patch makes use of the new AEAD interface which uses a single
> > SG list instead of separate lists for the AD and plain text.
>
> Looks fine - want me to run
Am Dienstag, 26. Mai 2015, 15:57:59 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 26, 2015 at 09:56:17AM +0200, Stephan Mueller wrote:
>> Actually, I mean the real in-kernel crypto API: the IKE daemon would set up
>> the SA via XFRM where the rfc4106(gcm(aes)) cipher is set
Am Dienstag, 26. Mai 2015, 16:18:01 schrieb Herbert Xu:
Hi Herbert,
>
>This is all in the patch series that you're responding. So please
>actually read it rather than making assumptions :)
Sorry, you are right -- I overlooked the xfrm_algo_desc change. Thanks for
helping.
Ciao
Stephan
--
To u
Am Dienstag, 26. Mai 2015, 15:38:59 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 26, 2015 at 09:37:09AM +0200, Stephan Mueller wrote:
>> - the current IKE implementations use rfc4106(gcm(aes)). They would need to
>> use seqniv(rfc4106(gcm(aes))) depending on the kernel version. S
Am Dienstag, 26. Mai 2015, 15:36:05 schrieb Herbert Xu:
Hi Herbert,
>
>In order to allow this to be done I'm going to disable the AEAD
>user-space interface in 4.1 so that we have time to fix it properly
>for 4.2.
Ok. Would you look into that one or shall I do that?
Ciao
Stephan
--
To unsubscrib
Am Dienstag, 26. Mai 2015, 15:21:52 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 26, 2015 at 08:39:56AM +0200, Stephan Mueller wrote:
>> May I also ask where I can find the generated IV when using
>> rfc4106(gcm(aes))?
>You need to use the IV generator, seqniv(rfc4106(gcm(aes))
Am Dienstag, 26. Mai 2015, 08:39:56 schrieb Stephan Mueller:
Hi,
>Am Freitag, 22. Mai 2015, 15:19:23 schrieb Herbert Xu:
>
>Hi Herbert,
>
>> On Fri, May 22, 2015 at 09:16:08AM +0200, Stephan Mueller wrote:
>> > Thanks for the pointer, but there I do not really see
Am Dienstag, 26. Mai 2015, 14:24:33 schrieb Herbert Xu:
Hi Herbert,
> On Mon, May 25, 2015 at 07:53:41PM +0800, Herbert Xu wrote:
> > On Mon, May 25, 2015 at 01:50:55PM +0200, Stephan Mueller wrote:
> > > When you have my code local, simply execute libkcapi/test/kcapi
Am Freitag, 22. Mai 2015, 15:19:23 schrieb Herbert Xu:
Hi Herbert,
> On Fri, May 22, 2015 at 09:16:08AM +0200, Stephan Mueller wrote:
> > Thanks for the pointer, but there I do not really see the functionality I
> > am looking for. I see patch 10/16 which seems to indicate
Am Montag, 25. Mai 2015, 18:20:21 schrieb Herbert Xu:
Hi Herbert,
> On Sun, May 24, 2015 at 12:52:02PM +0200, Stephan Mueller wrote:
> > [ 29.653113] BUG: unable to handle kernel NULL pointer dereference at
> > 000c
>
> Weird. I tried running your test b
Am Sonntag, 24. Mai 2015, 11:34:20 schrieb Herbert Xu:
Hi Herbert,
> On Sat, May 23, 2015 at 08:04:19PM +0200, Stephan Mueller wrote:
> > Am Freitag, 22. Mai 2015, 16:31:04 schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> > > This patch makes use of the ne
Am Samstag, 23. Mai 2015, 05:58:18 schrieb Herbert Xu:
Hi Herbert,
> On Fri, May 22, 2015 at 11:04:39PM +0200, Stephan Mueller wrote:
> > Note, gcm(aes) looks good. Only rfc4106(gcm(aes)) causes the crash.
>
> Actually it looks like the culprit hasn't been merged yet so I&
Am Freitag, 22. Mai 2015, 16:31:04 schrieb Herbert Xu:
Hi Herbert,
> This patch makes use of the new AEAD interface which uses a single
> SG list instead of separate lists for the AD and plain text.
After applying your additional patch, the "normal" AEAD operation works.
But with long messages
Am Freitag, 22. Mai 2015, 22:59:34 schrieb Stephan Mueller:
Hi Stephan,
> Am Freitag, 22. Mai 2015, 16:31:04 schrieb Herbert Xu:
>
> Hi Herbert,
>
> > This patch makes use of the new AEAD interface which uses a single
> > SG list instead of separate lists for the AD an
Am Freitag, 22. Mai 2015, 16:31:04 schrieb Herbert Xu:
Hi Herbert,
> This patch makes use of the new AEAD interface which uses a single
> SG list instead of separate lists for the AD and plain text.
Using an up-to date tree with the full set of patches of this patch set, I get
the following oop
Am Freitag, 22. Mai 2015, 14:45:54 schrieb Herbert Xu:
Hi Herbert,
>On Fri, May 22, 2015 at 08:40:25AM +0200, Stephan Mueller wrote:
>> If I may ask, where in your initial patch set is now decided that the IV
>> generator is used (i.e. so that the givcrypt API is not needed any m
Am Donnerstag, 21. Mai 2015, 18:44:03 schrieb Herbert Xu:
Hi Herbert,
>- aead_givcrypt_set_callback(req, 0, esp_output_done, skb);
>- aead_givcrypt_set_crypt(req, sg, sg, clen, iv);
>- aead_givcrypt_set_assoc(req, asg, assoclen);
>- aead_givcrypt_set_giv(req, esph->enc_data,
>
Am Donnerstag, 21. Mai 2015, 18:39:39 schrieb Herbert Xu:
Hi Herbert,
>Hi:
>
>This series of patches convert all in-tree AEAD users that I
>could find to the new single SG list interface. For IPsec it
>also adopts the new explicit IV generator scheme.
>
>To recap, the old AEAD interface takes an
30 matches
Mail list logo
