> Simple, you break a range policy into parts that can be expressed
> as network/mask and install multiple policies. The actual policies
> in the kernel just has to have the same effect as the one you
> negotiated with the other side, it does not have to look the same.
> This is also why you can
Fix a typo in the Kconfig file help text.
Signed-off-by: Valdis Kletnieks
---
Third time's the charm? Rebased to next-20111108 ("depends on NET"
caused the first 2 tries to not appy).
--- linux-next/crypto/Kconfig.dist 2011-11-06 01:35:20.423166379 -0400
+++ linux-next
On Fri, Nov 04, 2011 at 11:25:13AM -0400, Neil Horman wrote:
> On Fri, Nov 04, 2011 at 10:01:25AM -0400, Jarod Wilson wrote:
> > Apparently, NIST is tightening up its requirements for FIPS validation
> > with respect to RNGs. Its always been required that in fips mode, the
> > ansi cprng not be fed
On Sun, Nov 06, 2011 at 10:41:44AM +0100, Jörg Sommer wrote:
> Signed-off-by: Jörg Sommer
Your patch doesn't apply against my tree:
error: patch failed: crypto/Kconfig:104
error: crypto/Kconfig: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved
On Mon, Nov 07, 2011 at 01:51:51AM -0500, valdis.kletni...@vt.edu wrote:
> (Sent this a while back, I don't see it in next-2004, so resending)
>
> Fix a typo in the Kconfig file help text.
>
> Signed-off-by: Valdis Kletnieks
Your patch still does not apply:
$ git apply ~/p
error: patch fai
On Tue, Oct 18, 2011 at 01:32:08PM +0300, Jussi Kivilinna wrote:
> This series adds lrw_crypt() and xts_crypt() functions for cipher
> implementations that
> can benefit from parallel cipher block operations. To make interface
> flexible,
> caller is reponsible of allocating buffer large enough
On Tue, Oct 18, 2011 at 12:03:18AM +0300, Jussi Kivilinna wrote:
> Patch adds x86_64/SSE2 assembler implementation of serpent cipher. Assembler
> functions crypt data in eigth block chunks (two 4 block chunk SSE2 operations
> in parallel to improve performance on out-of-order CPUs). Glue code is ba
Daniil Stolnikov wrote:
>> Like I said, if you want address ranges, ask the userland IPSEC daemon
>> authors to synthesize it.
>
> In this letter, the mailing list
> http://marc.info/?l=strongswan-users&m=130613736616488&w=4 strongswan-users
> say that their product has support for IP ranges, b
Herbert Xu wrote:
> Alternatively you can do this with marking and use netfilter
> to set the mark.
> Cheers,
We focus on connections to devices zywall. If you choose to zywall IP range as
the remote side will not harmonize policies. The connection is not established.
And this alternative mak
> Like I said, if you want address ranges, ask the userland IPSEC daemon
> authors to synthesize it.
In this letter, the mailing list
http://marc.info/?l=strongswan-users&m=130613736616488&w=4 strongswan-users say
that their product has support for IP ranges, but the stack of Linux is based
on
David Miller wrote:
>
> Like I said, if you want address ranges, ask the userland IPSEC daemon
> authors to synthesize it.
Alternatively you can do this with marking and use netfilter
to set the mark.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://
From: Daniil Stolnikov
Date: Wed, 9 Nov 2011 09:36:07 +0800
> I never imagined that it will cause some difficulties.
Ever feature has side effects and costs associated with it. Some of
which can be non-trivial.
Like I said, if you want address ranges, ask the userland IPSEC daemon
authors to s
On Tue, 8 Nov 2011 19:34:57 -0600
Kim Phillips wrote:
> commit 3e721ae (crypto: talitos - handle descriptor not found in
> error path) used the wrong offset method to access a channel's
> descriptor buffer registers - the TALITOS_DESCBUF macro
> doesn't take a channel argument. Fix it to use the
> From: Daniil Stolnikov
> Date: Tue, 08 Nov 2011 12:40:13 +0400
>> I turned to you, the developers, but rather to urge you to implement
>> this feature using IP range.
> This won't be implemented, the keys used for IPSEC rule lookups supported by
> the kernel are already way too complex.
> Fro
commit 3e721ae (crypto: talitos - handle descriptor not found in
error path) used the wrong offset method to access a channel's
descriptor buffer registers - the TALITOS_DESCBUF macro
doesn't take a channel argument. Fix it to use the
base chan[x].reg offset instead.
Signed-off-by: Kim Phillips
From: Alexey Dobriyan
Date: Tue, 8 Nov 2011 14:08:24 +0200
> changing addr_match() is trivial for ipv4 and easy for ipv6. :-)
No, this is not happening. This added complexity screws up all the hash table
and lookup optimizations we have in the XFRM layer.
--
To unsubscribe from this list: send
From: Daniil Stolnikov
Date: Tue, 08 Nov 2011 12:40:13 +0400
> I turned to you, the developers, but rather to urge you to implement
> this feature using IP range.
This won't be implemented, the keys used for IPSEC rule lookups supported by
the kernel are already way too complex.
Ranges can be s
> On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr
> wrote:
>> On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:
>>> Hello!
>>>
>>> Found that the stack IPSec in Linux does not support any IP range. Many
>>> people ask this question. The archives say strongswan said that their
>>>
On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr
wrote:
> On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:
>> Hello!
>>
>> Found that the stack IPSec in Linux does not support any IP range. Many
>> people ask this question. The archives say strongswan said that their daemon
>> sup
> On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:
>> Hello!
>>
>> Found that the stack IPSec in Linux does not support any IP range. Many
>> people ask this question. The archives say strongswan said that their daemon
>> supports a range, but the Linux IPSec stack supports only the su
We leak the crypto instance when we unregister an instance with
crypto_del_alg(). Therefore we introduce crypto_unregister_instance()
to unlink the crypto instance from the template's instances list and
to free the recources of the instance properly.
Signed-off-by: Steffen Klassert
---
crypto/al
21 matches
Mail list logo
