Use ciphertext buffer length for determining ciphertext length

[jhfrontz]

The decrypt() routines mistakenly use the length of the plaintext buffer for determining the amount of data in the ciphertext buffer. On x86_64, a sufficiently large plaintext buffer will cause a segv/abort (see added tests). In other cases, it will silently overrun the ciphertext end and decrypt garbage.

This fix changes both decrypt() routines to use the ciphertext length instead.

[apoelstra]

utack 9c0ccd4 but needs reformatting

[jhfrontz]

@apoelstra I was confused about the formatting failure -- I had followed the existing formatting style. Should I deviate from it for this commit or re-format the entire routine to conform?

[apoelstra]

@jhfrontz the CI job shows formatting failures only in the assertions in the tests that you added. Just change those to match what the CI wants.

[apoelstra]

You are welcome to rant about rustfmt being a POS. If it annoys you too much we can switch to a model where we have a weekly cronjob that "fixes" the formatting, or to a model where we have no CI format checks, though I prefer to be running the tool regularly so that we don't need to discuss formatting changes in PRs.

But it is extremely unlikely that there is any combination of options that would lead to it enforcing a "consistent" style.

(BTW, the current source of "inconsistency" is that it has a line-length threshold at which it expects lines to be broken up. We could try setting that threshold to 0 or 100000, but there are multiple thresholds and the tool has built-in limits on how long a line it can read, and some thresholds are configurable only on a nightly compiler, and no matter what it won't leave meticulously-arranged byte arrays or vertically-aligned comments alone.)

[delta1]

@jhfrontz i think you just need to run cargo fmt —all

[jhfrontz]

Ah, I didn't notice that the length was short enough to satisfy "fits on one line". Fixed.