1. 09 Apr, 2014 3 commits
  2. 08 Apr, 2014 1 commit
  3. 07 Apr, 2014 1 commit
  4. 04 Apr, 2014 1 commit
  5. 26 Mar, 2014 3 commits
  6. 17 Mar, 2014 1 commit
  7. 13 Mar, 2014 2 commits
  8. 06 Feb, 2014 8 commits
  9. 22 Jan, 2014 2 commits
  10. 31 Dec, 2013 1 commit
  11. 30 Dec, 2013 1 commit
    • Paul Bakker's avatar
      Reduced the input / output overhead with 200+ bytes and covered corner · 956c9e06
      Paul Bakker authored
      case
      
      The actual input / output buffer overhead is only 301 instead of 512.
      This requires a proper check on the padding_idx to prevent out of bounds
      reads.
      
      Previously a remote party could potentially trigger an access error and
      thus stop the application when sending a malicious packet having
      MAX_CONTENT_LEN of data, 32 bytes of MAC and a decrypted padlen of .
      This would result in reading from in_ctr + 13 + 32 + MAX_CONTENT_LEN - 1 - 1
      for 256 bytes (including fake padding check). Or 13 + 32 bytes over the
      buffer length.
      
      We now reset padding_idx to 0, if it's clear that it will never be a
      valid padding (padlen > msg_len || msg_len + padlen + 256 > buffer_len)
      956c9e06
  12. 19 Dec, 2013 1 commit
  13. 17 Dec, 2013 4 commits
  14. 26 Nov, 2013 1 commit
  15. 19 Nov, 2013 1 commit
  16. 04 Nov, 2013 1 commit
  17. 31 Oct, 2013 2 commits
  18. 30 Oct, 2013 6 commits