audited using ineffassign tool from
github.com/gordonklaus/ineffassign
go generate does not generate any changes
Change-Id: Iabbec9ec1aae39081289d503d79fd7b4caadf17b
GitHub-Last-Rev: acd17cce410e9c68ce3c87b5546261be9153e3ea
GitHub-Pull-Request: golang/crypto#70
Reviewed-on: https://go-review.googlesource.com/c/155942
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Due to a missing return, corrupt TLV data would cause an infinite loop
that consumes memory, eventually crashing the process.
Thanks to Ivan Markin for pointing this out.
Change-Id: Iaaf7c5f7ce911d3e542b86f6b942b15e2ccbdf3b
Reviewed-on: https://go-review.googlesource.com/35247
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This serves as a basic sanity check and also prevents malformed private
keys from setting P=0 and consuming large amounts of CPU and memory in
the Exp call.
Change-Id: Ife22069b989a7347d8deaaf13030df82ee59e87b
Reviewed-on: https://go-review.googlesource.com/35246
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We have clang-format these days to eliminate any worries about C-code
formatting.
Change-Id: I86433d99f786ac4091c39eb4a41422c5a18d4d4a
Reviewed-on: https://go-review.googlesource.com/16937
Reviewed-by: Andrew Gerrand <adg@golang.org>
The test for this package contains a test case (disabled by default)
that exercises the code against libotr (the reference implementation).
Since that test was written, libotr has updated to version 4 which
contains non-backwards-compatible API changes.
This change updates the test harness for version 4 of libotr.
Change-Id: Ib40c899c609cc827903ae18fd80476d179bf0a33
Reviewed-on: https://go-review.googlesource.com/16936
Reviewed-by: Andrew Gerrand <adg@golang.org>
Since the test against libotr (disabled by default) runs forever, any
errors should be fatal otherwise they'll never be noticed.
Change-Id: Idf07dd963260f140be1950afcbd04331b56bd627
Reviewed-on: https://go-review.googlesource.com/16935
Reviewed-by: Andrew Gerrand <adg@golang.org>
The OTR implementation had a bug where key slots would not be marked as
unused after a rehandshake. Since handshaking resets the key ids, some
key slots would be left over with much higher key ids. These key slots
would lead to an error when the code ran out of slots.
Fixesagl/xmpp-client#96.
Change-Id: I013bbc4eaf0616373ab52f14b7f7757c353983ca
Reviewed-on: https://go-review.googlesource.com/16934
Reviewed-by: Andrew Gerrand <adg@golang.org>
* The other side is left hanging, waiting for their chance to do the
comparison.
Change-Id: I186933ebb53a30e190414c5572206851681e0a37
Reviewed-on: https://go-review.googlesource.com/15260
Reviewed-by: Adam Langley <agl@golang.org>
It's useful to expose this bit of state because, although callers can
keep track of it themselves, it's already in the Conversation so it
seems wasteful to make them do so.
R=golang-dev, ioerror
CC=golang-dev
https://golang.org/cl/6724056
The explicit OTR termination signal tells the peer that they should
discard their session keys and, more importantly, tells them that
*you* have done so and therefore cannot decrypt future messages.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/6430043