CT: Declassify sig in test instead of at the end of signing

[mkannwischer]

Alternative to #822 that I hope to be less controversial.
Currently the constant time tests for verification rely on the signature being declassified at the end of verification. This is not ideal. This commit moves this declassification to the constant-time test instead.

As suggested in
#822 (review), there is more work left to clean up the story around declassifications. This PR is a first step towards cleaning up that story to unblock #825 and #821, but there is more work left.

[hanno-becker]

@mkannwischer I don't understand why this is blocking #825. Can you elaborate?

[mkannwischer]

@mkannwischer I don't understand why this is blocking #825. Can you elaborate?

Prior to this PR there is a declassification of z prior to packing it into the signature buffer.
#825/#821 move the packing to earlier in the routine where z is, in fact, not yet independent of secrets and we cannot declassify it. So #825/#821 cannot be implemented without moving declassifications.
My thinking was that the right place to delassify the signature is outside of signing, but if you insist on declassifying it inside of signing, one can of course also just declassify in signing after everything has been packed. That is closest to what is implemented right now. I implemented that in #825 and #821 now making them independent of this PR.

[hanno-becker]

@mkannwischer I'm just trying to understand if the dependency can be avoided. If the intent of the current (main) code is to have the signature declassified, I think that should just be done explicitly at the end of signing. Would that not be cleaner and remove the dependency? We can still continue discussing if the signature should be declassified or not, but at least you can progress the RAM optimizations independently.