1. 05 12月, 2013 1 次提交
    • C
      crypto: more robust crypto_memneq · fe8c8a12
      Cesar Eduardo Barros 提交于
      Disabling compiler optimizations can be fragile, since a new
      optimization could be added to -O0 or -Os that breaks the assumptions
      the code is making.
      
      Instead of disabling compiler optimizations, use a dummy inline assembly
      (based on RELOC_HIDE) to block the problematic kinds of optimization,
      while still allowing other optimizations to be applied to the code.
      
      The dummy inline assembly is added after every OR, and has the
      accumulator variable as its input and output. The compiler is forced to
      assume that the dummy inline assembly could both depend on the
      accumulator variable and change the accumulator variable, so it is
      forced to compute the value correctly before the inline assembly, and
      cannot assume anything about its value after the inline assembly.
      
      This change should be enough to make crypto_memneq work correctly (with
      data-independent timing) even if it is inlined at its call sites. That
      can be done later in a followup patch.
      
      Compile-tested on x86_64.
      Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.eti.br>
      Acked-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      fe8c8a12
  2. 26 10月, 2013 1 次提交
  3. 07 10月, 2013 1 次提交
    • J
      crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks · 6bf37e5a
      James Yonan 提交于
      When comparing MAC hashes, AEAD authentication tags, or other hash
      values in the context of authentication or integrity checking, it
      is important not to leak timing information to a potential attacker,
      i.e. when communication happens over a network.
      
      Bytewise memory comparisons (such as memcmp) are usually optimized so
      that they return a nonzero value as soon as a mismatch is found. E.g,
      on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
      and up to ~850 cyc for a full match (cold). This early-return behavior
      can leak timing information as a side channel, allowing an attacker to
      iteratively guess the correct result.
      
      This patch adds a new method crypto_memneq ("memory not equal to each
      other") to the crypto API that compares memory areas of the same length
      in roughly "constant time" (cache misses could change the timing, but
      since they don't reveal information about the content of the strings
      being compared, they are effectively benign). Iow, best and worst case
      behaviour take the same amount of time to complete (in contrast to
      memcmp).
      
      Note that crypto_memneq (unlike memcmp) can only be used to test for
      equality or inequality, NOT for lexicographical order. This, however,
      is not an issue for its use-cases within the crypto API.
      
      We tried to locate all of the places in the crypto API where memcmp was
      being used for authentication or integrity checking, and convert them
      over to crypto_memneq.
      
      crypto_memneq is declared noinline, placed in its own source file,
      and compiled with optimizations that might increase code size disabled
      ("Os") because a smart compiler (or LTO) might notice that the return
      value is always compared against zero/nonzero, and might then
      reintroduce the same early-return optimization that we are trying to
      avoid.
      
      Using #pragma or __attribute__ optimization annotations of the code
      for disabling optimization was avoided as it seems to be considered
      broken or unmaintained for long time in GCC [1]. Therefore, we work
      around that by specifying the compile flag for memneq.o directly in
      the Makefile. We found that this seems to be most appropriate.
      
      As we use ("Os"), this patch also provides a loop-free "fast-path" for
      frequently used 16 byte digests. Similarly to kernel library string
      functions, leave an option for future even further optimized architecture
      specific assembler implementations.
      
      This was a joint work of James Yonan and Daniel Borkmann. Also thanks
      for feedback from Florian Weimer on this and earlier proposals [2].
      
        [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
        [2] https://lkml.org/lkml/2013/2/10/131Signed-off-by: NJames Yonan <james@openvpn.net>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Florian Weimer <fw@deneb.enyo.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6bf37e5a
  4. 24 9月, 2013 1 次提交
  5. 12 9月, 2013 1 次提交
    • H
      crypto: crct10dif - Add fallback for broken initrds · 26052f9b
      Herbert Xu 提交于
      Unfortunately, even with a softdep some distros fail to include
      the necessary modules in the initrd.  Therefore this patch adds
      a fallback path to restore existing behaviour where we cannot
      load the new crypto crct10dif algorithm.
      
      In order to do this, the underlying crct10dif has been split out
      from the crypto implementation so that it can be used on the
      fallback path.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      26052f9b
  6. 07 9月, 2013 1 次提交
  7. 24 7月, 2013 1 次提交
  8. 10 7月, 2013 1 次提交
  9. 20 5月, 2013 1 次提交
  10. 25 4月, 2013 1 次提交
  11. 20 1月, 2013 1 次提交
  12. 06 12月, 2012 1 次提交
  13. 08 10月, 2012 1 次提交
    • D
      KEYS: Implement asymmetric key type · 964f3b3b
      David Howells 提交于
      Create a key type that can be used to represent an asymmetric key type for use
      in appropriate cryptographic operations, such as encryption, decryption,
      signature generation and signature verification.
      
      The key type is "asymmetric" and can provide access to a variety of
      cryptographic algorithms.
      
      Possibly, this would be better as "public_key" - but that has the disadvantage
      that "public key" is an overloaded term.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      964f3b3b
  14. 01 8月, 2012 3 次提交
  15. 14 3月, 2012 2 次提交
  16. 30 11月, 2011 1 次提交
  17. 09 11月, 2011 1 次提交
  18. 21 10月, 2011 1 次提交
  19. 22 9月, 2011 2 次提交
  20. 14 3月, 2011 1 次提交
  21. 27 11月, 2010 1 次提交
  22. 26 11月, 2010 1 次提交
    • H
      crypto: algif_skcipher - User-space interface for skcipher operations · 8ff59090
      Herbert Xu 提交于
      This patch adds the af_alg plugin for symmetric key ciphers,
      corresponding to the ablkcipher kernel operation type.
      
      Keys can optionally be set through the setsockopt interface.
      
      Once a sendmsg call occurs without MSG_MORE no further writes
      may be made to the socket until all previous data has been read.
      
      IVs and and whether encryption/decryption is performed can be
      set through the setsockopt interface or as a control message
      to sendmsg.
      
      The interface is completely synchronous, all operations are
      carried out in recvmsg(2) and will complete prior to the system
      call returning.
      
      The splice(2) interface support reading the user-space data directly
      without copying (except that the Crypto API itself may copy the data
      if alignment is off).
      
      The recvmsg(2) interface supports directly writing to user-space
      without additional copying, i.e., the kernel crypto interface will
      receive the user-space address as its output SG list.
      
      Thakns to Miloslav Trmac for reviewing this and contributing
      fixes and improvements.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      8ff59090
  23. 19 11月, 2010 2 次提交
    • H
      crypto: algif_hash - User-space interface for hash operations · fe869cdb
      Herbert Xu 提交于
      This patch adds the af_alg plugin for hash, corresponding to
      the ahash kernel operation type.
      
      Keys can optionally be set through the setsockopt interface.
      
      Each sendmsg call will finalise the hash unless sent with a MSG_MORE
      flag.
      
      Partial hash states can be cloned using accept(2).
      
      The interface is completely synchronous, all operations will
      complete prior to the system call returning.
      
      Both sendmsg(2) and splice(2) support reading the user-space
      data directly without copying (except that the Crypto API itself
      may copy the data if alignment is off).
      
      For now only the splice(2) interface supports performing digest
      instead of init/update/final.  In future the sendmsg(2) interface
      will also be modified to use digest/finup where possible so that
      hardware that cannot return a partial hash state can still benefit
      from this interface.
      
      Thakns to Miloslav Trmac for reviewing this and contributing
      fixes and improvements.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Tested-by: NMartin Willi <martin@strongswan.org>
      fe869cdb
    • H
      crypto: af_alg - User-space interface for Crypto API · 03c8efc1
      Herbert Xu 提交于
      This patch creates the backbone of the user-space interface for
      the Crypto API, through a new socket family AF_ALG.
      
      Each session corresponds to one or more connections obtained from
      that socket.  The number depends on the number of inputs/outputs
      of that particular type of operation.  For most types there will
      be a s ingle connection/file descriptor that is used for both input
      and output.  AEAD is one of the few that require two inputs.
      
      Each algorithm type will provide its own implementation that plugs
      into af_alg.  They're keyed using a string such as "skcipher" or
      "hash".
      
      IOW this patch only contains the boring bits that is required
      to hold everything together.
      
      Thakns to Miloslav Trmac for reviewing this and contributing
      fixes and improvements.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Tested-by: NMartin Willi <martin@strongswan.org>
      03c8efc1
  24. 03 6月, 2010 2 次提交
  25. 07 1月, 2010 1 次提交
  26. 02 9月, 2009 1 次提交
  27. 06 8月, 2009 1 次提交
  28. 14 7月, 2009 1 次提交
  29. 04 3月, 2009 2 次提交
    • G
      crypto: zlib - New zlib crypto module, using pcomp · bf68e65e
      Geert Uytterhoeven 提交于
      Signed-off-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      bf68e65e
    • G
      crypto: compress - Add pcomp interface · a1d2f095
      Geert Uytterhoeven 提交于
      The current "comp" crypto interface supports one-shot (de)compression only,
      i.e. the whole data buffer to be (de)compressed must be passed at once, and
      the whole (de)compressed data buffer will be received at once.
      In several use-cases (e.g. compressed file systems that store files in big
      compressed blocks), this workflow is not suitable.
      Furthermore, the "comp" type doesn't provide for the configuration of
      (de)compression parameters, and always allocates workspace memory for both
      compression and decompression, which may waste memory.
      
      To solve this, add a "pcomp" partial (de)compression interface that provides
      the following operations:
        - crypto_compress_{init,update,final}() for compression,
        - crypto_decompress_{init,update,final}() for decompression,
        - crypto_{,de}compress_setup(), to configure (de)compression parameters
          (incl. allocating workspace memory).
      
      The (de)compression methods take a struct comp_request, which was mimicked
      after the z_stream object in zlib, and contains buffer pointer and length
      pairs for input and output.
      
      The setup methods take an opaque parameter pointer and length pair. Parameters
      are supposed to be encoded using netlink attributes, whose meanings depend on
      the actual (name of the) (de)compression algorithm.
      Signed-off-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      a1d2f095
  30. 19 2月, 2009 1 次提交
  31. 25 12月, 2008 1 次提交
    • H
      crypto: hash - Add shash interface · 7b5a080b
      Herbert Xu 提交于
      The shash interface replaces the current synchronous hash interface.
      It improves over hash in two ways.  Firstly shash is reentrant,
      meaning that the same tfm may be used by two threads simultaneously
      as all hashing state is stored in a local descriptor.
      
      The other enhancement is that shash no longer takes scatter list
      entries.  This is because shash is specifically designed for
      synchronous algorithms and as such scatter lists are unnecessary.
      
      All existing hash users will be converted to shash once the
      algorithms have been completely converted.
      
      There is also a new finup function that combines update with final.
      This will be extended to ahash once the algorithm conversion is
      done.
      
      This is also the first time that an algorithm type has their own
      registration function.  Existing algorithm types will be converted
      to this way in due course.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7b5a080b
  32. 10 12月, 2008 1 次提交
  33. 29 8月, 2008 1 次提交