Am Freitag, 24. April 2015, 07:21:05 schrieb Herbert Xu:
Hi Herbert,
>On Thu, Apr 23, 2015 at 03:42:19PM +0200, Stephan Mueller wrote:
>> Now, shall I kind of re-implement the chainiv ablkcipher wrapper into an IV
>> handler that just helps my code? That will be a lot of code for a simple
>> memc
On Fri, Apr 24, 2015 at 02:22:15AM +0200, Stephan Mueller wrote:
>
> I also have the givencrypt and givdecrypt functions. How would I directly
> hook
> them into the ablkcipher without using a reference for inst-
> >alg.cra_ablkcipher.geniv?
ablkcipher itself has givencrypt/givdecrypt so you don
On Thu, Apr 23, 2015 at 03:42:19PM +0200, Stephan Mueller wrote:
>
> Now, shall I kind of re-implement the chainiv ablkcipher wrapper into an IV
> handler that just helps my code? That will be a lot of code for a simple
> memcmp.
No no no. You don't need to do a template for givencrypt. chaini
Am Donnerstag, 23. April 2015, 10:55:58 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Apr 23, 2015 at 04:51:56AM +0200, Stephan Mueller wrote:
> > Encrypt input: IV, plaintext
> >
> > Encrypt output: processed IV, ciphertext
> >
> > Decrypt input: processed IV, ciphertext, IV to use for compare ope
On Thu, Apr 23, 2015 at 04:51:56AM +0200, Stephan Mueller wrote:
>
> Encrypt input: IV, plaintext
>
> Encrypt output: processed IV, ciphertext
>
> Decrypt input: processed IV, ciphertext, IV to use for compare operation
>
> Decrypt output: plaintext
Actually it is
Decrypt input: processed IV,
Am Donnerstag, 23. April 2015, 09:46:09 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Apr 23, 2015 at 03:39:11AM +0200, Stephan Mueller wrote:
> > The KW does not return an IV. The IV is used for encryption to stir the
> > encryption a bit. The resulting ciphertext now contains the mixed in IV.
> > F
On Thu, Apr 23, 2015 at 03:58:37AM +0200, Stephan Mueller wrote:
>
> So we have another memcpy just to copy that block into the IV field just to
> have the KW cipher implementation copy it to some other location again? I do
> not see the value of it.
But you already do that extra copy anyway:
+
Am Donnerstag, 23. April 2015, 09:46:09 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Apr 23, 2015 at 03:39:11AM +0200, Stephan Mueller wrote:
> > The KW does not return an IV. The IV is used for encryption to stir the
> > encryption a bit. The resulting ciphertext now contains the mixed in IV.
> > F
On Thu, Apr 23, 2015 at 03:39:11AM +0200, Stephan Mueller wrote:
>
> The KW does not return an IV. The IV is used for encryption to stir the
> encryption a bit. The resulting ciphertext now contains the mixed in IV. For
> decryption, the IV is only used to verify that the one block in the
> decr
Am Donnerstag, 23. April 2015, 09:33:37 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Apr 22, 2015 at 02:23:04PM +0200, Stephan Mueller wrote:
> > Isn't it a basic assumption to ablkcipher is that the ciphertext is equal
> > in size as the plaintext?
>
> Not necessarily since a blkcipher also output
Am Donnerstag, 23. April 2015, 09:39:28 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Apr 22, 2015 at 02:44:08PM +0200, Stephan Mueller wrote:
> > > Where does this 8-byte alignment requirement come from?
> >
> > Well, I am accessing the data in 8-byte chunks. Moreover, in the
> > scatterwalk copy f
On Wed, Apr 22, 2015 at 02:44:08PM +0200, Stephan Mueller wrote:
>
> > Where does this 8-byte alignment requirement come from?
>
> Well, I am accessing the data in 8-byte chunks. Moreover, in the scatterwalk
> copy functions, I search through the scatterlists in 8 byte increments. If,
> say, a s
On Wed, Apr 22, 2015 at 04:11:08PM +0200, Stephan Mueller wrote:
>
> One more issue to consider: the key wrapping is an authenticated encryption /
> decryption. Thus, decryption can return EBADMSG, a feature a normal blkcipher
> does not do.
We currently have a givdecrypt function that's complet
On Wed, Apr 22, 2015 at 02:23:04PM +0200, Stephan Mueller wrote:
>
> Isn't it a basic assumption to ablkcipher is that the ciphertext is equal in
> size as the plaintext?
Not necessarily since a blkcipher also outputs IV which is exactly
what's happening in KW.
For the fixed IV value you could u
Am Mittwoch, 22. April 2015, 14:23:04 schrieb Stephan Mueller:
Hi,
> Am Mittwoch, 22. April 2015, 14:13:54 schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Wed, Apr 22, 2015 at 01:53:24PM +0800, Herbert Xu wrote:
> > > On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
> > > > The key
Am Mittwoch, 22. April 2015, 13:48:46 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
> > +static int crypto_kw_decrypt(struct aead_request *req)
> > +{
> > + struct crypto_aead *aead = crypto_aead_reqtfm(req);
> > + struct crypto_kw_ctx *ctx
Am Mittwoch, 22. April 2015, 14:13:54 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Apr 22, 2015 at 01:53:24PM +0800, Herbert Xu wrote:
> > On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
> > > The key wrapping is an authenticated encryption operation without
> > > associated data. T
On Wed, Apr 22, 2015 at 01:53:24PM +0800, Herbert Xu wrote:
> On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
> >
> > The key wrapping is an authenticated encryption operation without
> > associated data. Therefore, setting of AAD is permissible, but that data
> > is not used by t
On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
>
> + if (req->iv)
> + ret = crypto_memneq(block.A, req->iv, SEMIBSIZE);
> + else
> + ret = crypto_memneq(block.A, default_iv, SEMIBSIZE);
No we don't allow variable-sized IVs. Either you should alway
On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
>
> The key wrapping is an authenticated encryption operation without
> associated data. Therefore, setting of AAD is permissible, but that data
> is not used by the cipher implementation.
In that case you should return an error if
On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
>
> +static int crypto_kw_decrypt(struct aead_request *req)
> +{
> + struct crypto_aead *aead = crypto_aead_reqtfm(req);
> + struct crypto_kw_ctx *ctx = crypto_aead_ctx(aead);
> + struct crypto_cipher *tfm = ctx->child;
>
21 matches
Mail list logo
