doc.go 2.9 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768
  1. // Copyright 2014 The Go Authors. All rights reserved.
  2. // Use of this source code is governed by a BSD-style
  3. // license that can be found in the LICENSE file.
  4. // Package sha3 implements the SHA-3 fixed-output-length hash functions and
  5. // the SHAKE variable-output-length hash functions defined by FIPS-202.
  6. //
  7. // Both types of hash function use the "sponge" construction and the Keccak
  8. // permutation. For a detailed specification see http://keccak.noekeon.org/
  9. //
  10. //
  11. // Guidance
  12. //
  13. // If you aren't sure what function you need, use SHAKE256 with at least 64
  14. // bytes of output.
  15. //
  16. // If you need a secret-key MAC (message authentication code), prepend the
  17. // secret key to the input, hash with SHAKE256 and read at least 32 bytes of
  18. // output.
  19. //
  20. //
  21. // Security strengths
  22. //
  23. // The SHA3-x functions have a security strength against preimage attacks of x
  24. // bits. Since they only produce x bits of output, their collision-resistance
  25. // is only x/2 bits.
  26. //
  27. // The SHAKE-x functions have a generic security strength of x bits against
  28. // all attacks, provided that at least 2x bits of their output is used.
  29. // Requesting more than 2x bits of output does not increase the collision-
  30. // resistance of the SHAKE functions.
  31. //
  32. //
  33. // The sponge construction
  34. //
  35. // A sponge builds a pseudo-random function from a pseudo-random permutation,
  36. // by applying the permutation to a state of "rate + capacity" bytes, but
  37. // hiding "capacity" of the bytes.
  38. //
  39. // A sponge starts out with a zero state. To hash an input using a sponge, up
  40. // to "rate" bytes of the input are XORed into the sponge's state. The sponge
  41. // has thus been "filled up" and the permutation is applied. This process is
  42. // repeated until all the input has been "absorbed". The input is then padded.
  43. // The digest is "squeezed" from the sponge by the same method, except that
  44. // output is copied out.
  45. //
  46. // A sponge is parameterized by its generic security strength, which is equal
  47. // to half its capacity; capacity + rate is equal to the permutation's width.
  48. //
  49. // Since the KeccakF-1600 permutation is 1600 bits (200 bytes) wide, this means
  50. // that security_strength == (1600 - bitrate) / 2.
  51. //
  52. //
  53. // Recommendations, detailed
  54. //
  55. // The SHAKE functions are recommended for most new uses. They can produce
  56. // output of arbitrary length. SHAKE256, with an output length of at least
  57. // 64 bytes, provides 256-bit security against all attacks.
  58. //
  59. // The Keccak team recommends SHAKE256 for most applications upgrading from
  60. // SHA2-512. (NIST chose a much stronger, but much slower, sponge instance
  61. // for SHA3-512.)
  62. //
  63. // The SHA-3 functions are "drop-in" replacements for the SHA-2 functions.
  64. // They produce output of the same length, with the same security strengths
  65. // against all attacks. This means, in particular, that SHA3-256 only has
  66. // 128-bit collision resistance, because its output length is 32 bytes.
  67. package sha3 // import "golang.org/x/crypto/sha3"