All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dimitrios Siganos <dimitris@siganos.org>
To: linux-crypto@vger.kernel.org
Subject: Re: CRYPTO_TFM_REQ_MASK and CRYPTO_TFM_RES_MASK
Date: Fri, 11 Dec 2009 15:28:12 +0000	[thread overview]
Message-ID: <4B22650C.1000505@siganos.org> (raw)
In-Reply-To: <4B225FCB.5050606@siganos.org>

After sending the email, I realised what's happening... 
crypto_cipher_setkey seems to be used that way only when a child cipher 
is used by another (parent) cipher as a way to delegate work.

It seems that crypto_cipher_setkey accepts a number of request flags 
CRYPTO_TFM_REQ_* which must be passed to the child object and after 
completion of crypto_cipher_setkey, it returns some results flags 
CRYPTO_TFM_RES_* back which must be passed to the parent object.

So the flag manipulation before and after is because we are using an 
internal cipher object to delegate the work.

Please correct me, if I am wrong.

Dimitris

Dimitrios Siganos wrote:
> Hi,
>
> Could someone explain what the masks CRYPTO_TFM_REQ_MASK and 
> CRYPTO_TFM_RES_MASK do and why they must be manipulated before and 
> after crypto_cipher_setkey(...)?
>
> Here is an example use (from crypto_pcbc_setkey):
>    crypto_cipher_clear_flags(child, CRYPTO_TFM_REQ_MASK);
>    crypto_cipher_set_flags(child, crypto_tfm_get_flags(parent) &
>                CRYPTO_TFM_REQ_MASK);
>    err = crypto_cipher_setkey(child, key, keylen);
>    crypto_tfm_set_flags(parent, crypto_cipher_get_flags(child) &
>                 CRYPTO_TFM_RES_MASK);
>
> It would be very useful if someone added some comments to these 
> definitions (found in linux/crypto.h):
>
> /*
> * Transform masks and values (for crt_flags).
> */
> #define CRYPTO_TFM_REQ_MASK        0x000fff00
> #define CRYPTO_TFM_RES_MASK        0xfff00000
>
> #define CRYPTO_TFM_REQ_WEAK_KEY        0x00000100
> #define CRYPTO_TFM_REQ_MAY_SLEEP    0x00000200
> #define CRYPTO_TFM_REQ_MAY_BACKLOG    0x00000400
> #define CRYPTO_TFM_RES_WEAK_KEY        0x00100000
> #define CRYPTO_TFM_RES_BAD_KEY_LEN       0x00200000
> #define CRYPTO_TFM_RES_BAD_KEY_SCHED     0x00400000
> #define CRYPTO_TFM_RES_BAD_BLOCK_LEN     0x00800000
> #define CRYPTO_TFM_RES_BAD_FLAGS     0x01000000
>
> Thanks,
> Dimitris
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2009-12-11 15:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-11 15:05 CRYPTO_TFM_REQ_MASK and CRYPTO_TFM_RES_MASK Dimitrios Siganos
2009-12-11 15:28 ` Dimitrios Siganos [this message]
2009-12-12  8:22   ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B22650C.1000505@siganos.org \
    --to=dimitris@siganos.org \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.