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>
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
Adam Langley
Arlo Breault
Reinaldo de Souza Jr
David Symonds
Frithjof Schulze