On 06/11/07 21:01 +0100, Sebastian Siewior wrote:
> Currently the Geode AES module fails to encrypt or decrypt if
> the coherent bits are not set what is currently the case if the
> encryption does not occur inplace. However, the encryption works
> on my Geode machine _only_ if the coherent bits a
Currently the Geode AES module fails to encrypt or decrypt if
the coherent bits are not set what is currently the case if the
encryption does not occur inplace. However, the encryption works
on my Geode machine _only_ if the coherent bits are always set.
Cc: Jordan Crouse <[EMAIL PROTECTED]>
Sign
This patch implements Salsa20, an eSTREAM candidate. This patch should
be applied after the "stream" patch.
Notable differences from my first posting (25 Oct):
1. Smaller test vectors are used. Instead of 512 bytes, now I use 38,
64, 111 and 129 instead. Reason: (a.) to test a variety of lengths
t
Added a "stream" template to support stream ciphers (eSTREAM
candidates in particular) within the CryptoAPI framework.
The current patch differed from my first posting (25 Oct) to the
mailing list in several ways:
1. It now uses cia_setiv() only instead of cia_setiv_crypt() in
include/linux/crypto
On 04/11/07 21:59 +0100, Sebastian Siewior wrote:
> The Geode AES crypto engine supports only 128 bit long key. This
> patch adds fallback for other key sizes which are required by the
> AES standard.
>
> Cc: Jordan Crouse <[EMAIL PROTECTED]>
> Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
Hi Evgeniy,
Thanks for the reply. Unfortunately my previous email did not make it
on to the mailing list (it is blocked by Majorodomo as it exceeded
100,000 bytes) so only you and Herbert received it. The rest of the
reader would surely be confused by our current exchange. My apologies!
I have re
* Jonathan Lynch | 2007-11-06 18:28:00 [+]:
>SHA-224 should be chosen as a hash algorithm when 112 bits of security
>strength is required.
Who uses such an algorithm (in terms of application)?
>diff -uprN -X linux-2.6.24-rc1-vanilla/Documentation/dontdiff
>linux-2.6.24-rc1-vanilla/crypto/tc
This patch extends sha256_generic.c to support SHA-224 as described in
FIPS 180-2 and RFC 3874. HMAC-SHA-224 as described in RFC4231 is then
supported through the hmac interface.
SHA-224 should be chosen as a hash algorithm when 112 bits of security
strength is required.
Patch includes test vect
On Thu, Oct 25, 2007 at 12:48:29PM +0100, Denys Vlasenko wrote:
> On Thursday 25 October 2007 12:43, Denys Vlasenko wrote:
> > Hi Hervert,
> >
> > Please review and maybe propagate upstream following patches.
> >
> > camellia5.diff
> > Use alternative key setup implementation with mostly 64-b
On Thu, Oct 25, 2007 at 12:47:16PM +0100, Denys Vlasenko wrote:
> On Thursday 25 October 2007 12:43, Denys Vlasenko wrote:
> > Hi Hervert,
> >
> > Please review and maybe propagate upstream following patches.
> >
> > camellia4.diff
> > Move huge unrolled pieces of code (3 screenfuls) at the e
On Thu, Oct 25, 2007 at 12:46:35PM +0100, Denys Vlasenko wrote:
> On Thursday 25 October 2007 12:43, Denys Vlasenko wrote:
> > Hi Hervert,
> >
> > Please review and maybe propagate upstream following patches.
> >
> > camellia3.diff
> > Optimize GETU32 to use 4-byte memcpy (modern gcc will con
On Thu, Oct 25, 2007 at 12:45:42PM +0100, Denys Vlasenko wrote:
> On Thursday 25 October 2007 12:43, Denys Vlasenko wrote:
> > Hi Hervert,
> >
> > Please review and maybe propagate upstream following patches.
> >
> > camellia2.diff
> > Rename some macros to shorter names: CAMELLIA_RR8 -> ROR8
On Thu, Oct 25, 2007 at 12:45:04PM +0100, Denys Vlasenko wrote:
> On Thursday 25 October 2007 12:43, Denys Vlasenko wrote:
> > Hi Hervert,
> >
> > Please review and maybe propagate upstream following patches.
> >
> > camellia1.diff:
> > Move code blocks around so that related pieces are close
Hi.
On Sun, Nov 04, 2007 at 01:35:14AM +0800, Tan Swee Heng ([EMAIL PROTECTED])
wrote:
> CHANGES
> 1. stream.c's blocksize is now 1 since (i) it makes more sense and
> (ii) the latest 2.6.24-rc1 git allows it.
> 2. SOSEMANUK, another eSTREAM candidate, has been ported.
> 3. Got rid of "coding sty
Hi,
While working with openswan 2.4.9 on kernel 2.6.22.7 I found a bug in file
sysctl_net_ipsec.c.
The initialization of ipsec_table is improper for newer kernel versions since
ctl_table structure was updated.
The 7th parameter which refer to *parent was initialized mistakenly with
*proc_handl
15 matches
Mail list logo