RE: [PATCH 2/3] sha512: reduce stack usage to safe number

2012-01-16 Thread David Laight
Doesn't this badly overflow W[] ..
 
 +#define SHA512_0_15(i, a, b, c, d, e, f, g, h) \
 + t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i];  \
...
 + for (i = 0; i  16; i += 8) {
...
 + SHA512_0_15(i + 7, b, c, d, e, f, g, h, a);
 + }

David


--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] sha512: reduce stack usage to safe number

2012-01-16 Thread Alexey Dobriyan
On 1/16/12, David Laight david.lai...@aculab.com wrote:
 Doesn't this badly overflow W[] ..

 +#define SHA512_0_15(i, a, b, c, d, e, f, g, h) \
 +t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i];  \
 ...
 +for (i = 0; i  16; i += 8) {
 ...
 +SHA512_0_15(i + 7, b, c, d, e, f, g, h, a);
 +}

No, why should it?
i can be only 0 and 8.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 2/3] sha512: reduce stack usage to safe number

2012-01-16 Thread Eric Dumazet
Le lundi 16 janvier 2012 à 09:56 +, David Laight a écrit :
 Doesn't this badly overflow W[] ..
  
  +#define SHA512_0_15(i, a, b, c, d, e, f, g, h) \
  +   t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i];  \
 ...
  +   for (i = 0; i  16; i += 8) {
 ...
  +   SHA512_0_15(i + 7, b, c, d, e, f, g, h, a);
  +   }
 
   David
 
 

No overflow since loop is done for only i=0 and i=8

By the way, I suspect previous code was chosen years ago because this
version uses less stack but adds much more code bloat.


size crypto/sha512_generic.o crypto/sha512_generic_old.o
   textdata bss dec hex filename
  17369 704   0   180734699 crypto/sha512_generic.o
   8249 704   0895322f9 crypto/sha512_generic_old.o



--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 07/21] KEYS: Create a key type that can be used for general cryptographic operations [ver #3]

2012-01-16 Thread Mimi Zohar
On Fri, 2011-12-02 at 18:43 +, David Howells wrote:
 Create a key type that can be used for general cryptographic operations, such
 as encryption, decryption, signature generation and signature verification.
 
 The key type is crypto and can provide access to a variety of cryptographic
 algorithms.
 
 Signed-off-by: David Howells dhowe...@redhat.com

Nice! Basically the 'crypto' key type ties crypto/ with security/keys.
Other than the posted pgp key parser used for verifying kernel module
signatures, I assume another use case could be to expose kernel
cryptography to userspace.  As there was a submission
https://lkml.org/lkml/2010/8/20/103 to do just this, there must be
userspace apps that would benefit.  This architecture would address a
number of concerns raised with the prior submission. (Refer to
http://lwn.net/Articles/401548/.)

You'd probably want to move the 'crypto' key type to its own directory.

Acked-by: Mimi Zohar zo...@us.ibm.com

thanks,
Mimi

 ---
 
  Documentation/security/keys-crypto.txt |  181 +
  include/keys/crypto-subtype.h  |   56 
  include/keys/crypto-type.h |   25 +++
  security/keys/Kconfig  |8 +
  security/keys/Makefile |3 
  security/keys/crypto_keys.h|   28 
  security/keys/crypto_type.c|  230 
 
  7 files changed, 531 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/security/keys-crypto.txt
  create mode 100644 include/keys/crypto-subtype.h
  create mode 100644 include/keys/crypto-type.h
  create mode 100644 security/keys/crypto_keys.h
  create mode 100644 security/keys/crypto_type.c
 
 
 diff --git a/Documentation/security/keys-crypto.txt 
 b/Documentation/security/keys-crypto.txt
 new file mode 100644
 index 000..97dee80
 --- /dev/null
 +++ b/Documentation/security/keys-crypto.txt
 @@ -0,0 +1,181 @@
 + ==
 + CRYPTOGRAPHIC KEY TYPE
 + ==
 +
 +Contents:
 +
 +  - Overview.
 +  - Key identification.
 +  - Accessing crypto keys.
 +  - Implementing crypto parsers.
 +  - Implementing crypto subtypes.
 +
 +
 +
 +OVERVIEW
 +
 +
 +The crypto key type is designed to be a container for cryptographic keys,
 +without imposing any particular restrictions on the form of the cryptography 
 or
 +the key.
 +
 +The crypto key is given a subtype that defines what sort of data is 
 associated
 +with the key and provides operations to describe and destroy it.  However, no
 +requirement is made that the key data actually be loaded into the key.
 +
 +The crypto key also has a number of data parsers registered with it.  The 
 data
 +parsers are responsible for extracing information the blobs of data passed to
 +the instantiator function.  The first data parser that recognises the blob 
 gets
 +to set the subtype of the key and define the operations that can be done on
 +that key.
 +
 +Completely in-kernel key retention and operation subtypes and parsers can be
 +defined, but it would also be possible to provide access to cryptographic
 +hardware (such as a TPM) that might be used to both retain the relevant key 
 and
 +perform operations using that key.  In such a case, the crypto key would then
 +merely be an interface to the TPM driver.
 +
 +
 +==
 +KEY IDENTIFICATION
 +==
 +
 +Because the identity of a key is not necessarily known and may not be easily
 +calculated when a crypto key is allocated, it may not be a simple matter to 
 set
 +a key description to something that's useful for determining whether this is
 +the key you're looking for.  Furthermore, it may be necessary to perform a
 +partial match upon the key identity.
 +
 +To help with this, when a key is loaded, the parser calculates the key
 +fingerprint and stores a copy in the key structure.
 +
 +The crypto key type's key matching function then performs more checks than 
 just
 +the straightforward comparison of the description with the criterion string:
 +
 + (1) If the criterion string is of the form id:hexdigits then the match
 + function will examine a key's fingerprint to see if the hex digits given
 + after the id: match the tail.  For instance:
 +
 + keyctl search @s crypto id:5acc2142
 +
 + will match a key with fingerprint:
 +
 + 1A00 2040 7601 7889 DE11  882C 3823 04AD 5ACC 2142
 +
 + (2) If the criterion string is of the form subtype:hexdigits then the
 + match will match the ID as in (1), but with the added restriction that
 + only keys of the specified subtype (e.g. dsa or rsa) will be matched.  
 For
 + instance:
 +
 + keyctl search @s crypto dsa:5acc2142
 +
 +Looking in /proc/keys, the last 8 hex digits of the key fingerprint are
 +displayed, along with the subtype:
 +
 + 1a39e171 I- 1 perm 3f01 0 0 cryptomodsign.0: 
 DSA