On Wed, 2008-01-16 at 19:10 -0500, Kevin Coffman wrote:
> On Jan 16, 2008 6:24 PM, Joy Latten <[EMAIL PROTECTED]> wrote:
> > On Wed, 2008-01-16 at 16:51 -0500, Kevin Coffman wrote:
> > > On Jan 16, 2008 4:13 PM, Joy Latten <[EMAIL PROTECTED]> wrote:
> > > >
On Wed, 2008-01-16 at 16:51 -0500, Kevin Coffman wrote:
> On Jan 16, 2008 4:13 PM, Joy Latten <[EMAIL PROTECTED]> wrote:
> > On Tue, 2008-01-15 at 15:28 -0500, Kevin Coffman wrote:
> > > Hello,
> > > I need to implement AES with CTS mode for NFSv4 (rfc39
On Wed, 2008-01-16 at 15:13 -0600, Joy Latten wrote:
> On Tue, 2008-01-15 at 15:28 -0500, Kevin Coffman wrote:
> > Hello,
> > I need to implement AES with CTS mode for NFSv4 (rfc3962 & rfc4121).
> >
> > I have implemented CTS starting with a copy of CBC (crypto/cb
On Tue, 2008-01-15 at 15:28 -0500, Kevin Coffman wrote:
> Hello,
> I need to implement AES with CTS mode for NFSv4 (rfc3962 & rfc4121).
>
> I have implemented CTS starting with a copy of CBC (crypto/cbc.c),
> since CTS is the same as CBC except for the last two blocks.
>
I am not sure I understa
>On Tue, Dec 11, 2007 at 04:24:26AM -0600, Joy Latten wrote:
>>
>> Please let me know if all looks ok or not.
>> I may need to rebase this patch or change something in
>> light of Herbert's recent patchsets. I will take a look
>> at them later today.
>
&g
.
I may need to rebase these patches in light of Herbert's
recent patchset.
regards,
Joy
Signed-off-by: Joy Latten <[EMAIL PROTECTED]>
~
diff -urpN cryptodev-2.6.2.sb/crypto/tcrypt.c
cryptodev-2.6.2.sb2/crypto/tcrypt.c
--- cryptodev-2.6.2.sb/crypto/tcrypt.c 2007-12-11 03:27:15.
Joy
Signed-off-by: Joy Latten <[EMAIL PROTECTED]>
diff -urpN cryptodev-2.6.2/crypto/ccm.c cryptodev-2.6.2.sb/crypto/ccm.c
--- cryptodev-2.6.2/crypto/ccm.c1969-12-31 18:00:00.0 -0600
+++ cryptodev-2.6.2.sb/crypto/ccm.c 2007-12-11 03:46:21.0 -0600
@@ -0,0 +1,558 @@
: Joy Latten <[EMAIL PROTECTED]>
diff -urpN cryptodev-2.6.2/crypto/scatterwalk.c
cryptodev-2.6.2.sandbox/crypto/scatterwalk.c
--- cryptodev-2.6.2/crypto/scatterwalk.c2007-12-05 00:23:37.0
-0600
+++ cryptodev-2.6.2.sandbox/crypto/scatterwalk.c2007-12-06
00:10:56.000
On Fri, 2007-10-26 at 14:59 +0800, Herbert Xu wrote:
>On Tue, Oct 23, 2007 at 03:26:29PM -0500, Joy Latten wrote:
> >
> > + err = crypto_attr_u32(tb[4], &countersize);
> > + if (err)
> > + goto out_put_alg;
> > +
> > /* verify size of no
for incrementing. CTR will increment counter
portion by 1, and begin encryption with that value.
Note that CTR assumes the counter portion of the block that
will be incremented is stored in big endian.
Please let me know if this looks ok.
Regards,
Joy
Signed-off-by: Joy Latten <[EMAIL PROTEC
>On Fri, Oct 19, 2007 at 10:29:32PM +0000, Joy Latten wrote:
>>
>> I think the change to CTR would be simple.
>> If noncesize + ivsize == blocksize, then use
>> entire counterblock as counter and pass to
>> ctr_inc_quad(). Currently, we just fail
>
ering about a slight compatibility glitch between
> CTR and GCM with Joy Latten. As CTR and GCM are very similar, the
> way to go with GCM is obviously to implement it on top of CTR.
> The problem is that CTR and GCM use different counter portion
> values for the first encrypted plaintex
On Wed, 2007-10-10 at 23:17 +0800, Herbert Xu wrote:
> On Tue, Oct 09, 2007 at 02:44:40PM -0500, Joy Latten wrote:
> > This should contain the geniv as well as all the
> > improvements discussed. All the testcases pass.
>
> This looks pretty good!
>
> I'm going
On Wed, 2007-10-10 at 23:17 +0800, Herbert Xu wrote:
> On Tue, Oct 09, 2007 at 02:44:40PM -0500, Joy Latten wrote:
> > This should contain the geniv as well as all the
> > improvements discussed. All the testcases pass.
>
> This looks pretty good!
>
> I'm going
/crypto/ctr.c2007-10-09 12:12:54.0
-0500
@@ -0,0 +1,375 @@
+/*
+ * CTR: Counter mode
+ *
+ * (C) Copyright IBM Corp. 2007 - Joy Latten <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General
On Wed, 2007-10-03 at 18:21 +0800, Herbert Xu wrote:
> We can't assume that the counter block is always 16 bytes
> since that depends on the underlying block size. It's probably
> easiest if the caller computes the correct counter position and
> gives that to us.
>
> BTW, it isn't that hard to su
On Wed, 2007-10-03 at 18:28 +0800, Herbert Xu wrote:
> On Wed, Oct 03, 2007 at 06:21:49PM +0800, Herbert Xu wrote:
>
> > static void __ctr_inc_byte(u8 *a, int size)
> > {
> > __be8 *b = (__be8 *)(a + size);
> > u8 c;
> >
> > do {
> > c = be8_to_cpu(*--b) + 1;
> >
{
@@ -434,8 +450,16 @@ static int crypto_init_blkcipher_ops_async(struct
crypto_tfm *tfm)
crt->setkey = async_setkey;
crt->encrypt = async_encrypt;
crt->decrypt = async_decrypt;
+ crt->geniv = async_geniv;
crt->ivsize = alg->ivsize;
+ if (!alg->geniv)
>On Thu, Sep 27, 2007 at 03:54:51PM -0500, Joy Latten wrote:
>>
>>So, for example,
>>
>> ctr(aes,4,8)
>>
>>specifies the counter block will be composed of 4 bytes from a
>>nonce and 8 bytes from the IV and 4 bytes for cou
Sorry, I really messed up my Subject header.
This comment was for [PATCH 2/8] [CRYPTO] aead: Add support for
multiple template parameters in the patchset.
The second patch in patch set, not the eighth.
Joy
On Thu, 2007-09-27 at 17:25 -0500, Joy Latten wrote:
> My apologies for such late not
Again, sorry for the late notice, but this just came
to my attention.
+static struct crypto_instance *crypto_authenc_alloc(struct rtattr **tb)
+{
+ struct crypto_instance *inst;
+ struct crypto_alg *auth;
+ struct crypto_alg *enc;
+ struct authenc_instance_ctx *ctx;
+
My apologies for such late notice, but I observed this only recently
and wanted to point it out.
if (!try_module_get(THIS_MODULE))
goto err;
@@ -101,33 +106,73 @@ static int cryptomgr_schedule_probe(struct crypto_larval
*larval)
memcpy(param->template, name, le
ones with 256-bit keys.
Please let me know if all looks ok or not.
Signed-off-by: Joy Latten <[EMAIL PROTECTED]>
diff -urpN linux-2.6.22.aead/crypto/ctr.c linux-2.6.22.aead.patch/crypto/ctr.c
--- linux-2.6.22.aead/crypto/ctr.c 1969-12-31 18:00:00.0 -0600
+++ linux-2.6.22.aead
>> > I suggest that you make these parameters to your CTR template.
>> > So instead of requesting for "ctr(aes)", you could request for
>> > "ctr(aes, 4, 8)" where 4 is the length of the nonce in the
>> > counter block and 8 is the length of the IV. The counter
>> > itself would then be calculated
On Thu, 2007-09-20 at 16:19 +0800, Herbert Xu wrote:
> On Wed, Sep 19, 2007 at 05:51:15PM -0500, Joy Latten wrote:
> >
> > predictability into my sessions? I could truncate the salt
> > in my counter block to 2 bytes and put 2 bytes of the IV for
> > blocksizes of 8...
On Wed, 2007-09-19 at 21:06 +0800, Herbert Xu wrote:
> > + do {
> > + /* create keystream */
> > + fn(crypto_cipher_tfm(tfm), dst, ctrblk);
> > + xor_128(dst, src);
>
> You seem to be assuming that the cipher algorithm is AES.
> That's not necessarily the case so
Corp. 2007 - Joy Latten <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later v
>
>The salt will just come from the key field. So instead of having
>an 128-bit key for example, you'd have 152 bits.
ok, quick question, this 152 bits key will be part
of input to setkey()?
The reason I am asking is because setkey in ablkcipher and
blkcipher check key length for min and max siz
On Fri, 2007-08-17 at 10:19 +0800, Herbert Xu wrote:
> Joy Latten <[EMAIL PROTECTED]> wrote:
> > I am in learning mode and have been looking into CTR.
> > Based on the fact that CTR does not require the plaintext to
> > be a multiple of the blocksize nor is padding
I am in learning mode and have been looking into CTR.
Based on the fact that CTR does not require the plaintext to
be a multiple of the blocksize nor is padding required,
should I use cipher.c routines (as xcbc does) instead
of blkcipher.c routines (as cbc does)?
(I've been referencing rfc 3686.)
On Wed, 2007-07-18 at 12:46 +0800, Herbert Xu wrote:
> On Tue, Jun 26, 2007 at 10:02:36AM -0500, Joy Latten wrote:
> >
> > Ok, thanks. This helps. I can code up the infrastructure for this. I
> > am thinking I will eventually need one of the algorithms to test and
> &g
On Tue, 2007-06-26 at 13:09 +0400, Evgeniy Polyakov wrote:
> On Mon, Jun 25, 2007 at 05:13:58PM -0500, Joy Latten ([EMAIL PROTECTED])
> wrote:
> > I have been reading IP Encapsulating Payload-(ESP) RFC4303 where use of
> > combined mode algorithms are mentioned and accommo
I have been reading IP Encapsulating Payload-(ESP) RFC4303 where use of
combined mode algorithms are mentioned and accommodated for.
In trying to determine how I should handle this, I examined the
crypto code and could not readily recognize any combined mode
algorithms. Are there any current plans
33 matches
Mail list logo
