Reject NaN in ClampFloat64 and check L1 sensitivity overflow in Laplace noise

[AndyBurecovics]

ClampFloat64 does not handle NaN inputs. Because IEEE 754 comparisons with NaN return false, NaN passes through clamping untouched and propagates into DP results, breaking the privacy guarantee.

NaN reaches ClampFloat64 through L1 sensitivity overflow in the Laplace noise layer: when lInfSensitivity * l0Sensitivity overflows to +Inf, ceilPowerOfTwo returns NaN, and the noise computation produces NaN throughout.

This patch:

• Rejects NaN/Inf bounds in ClampFloat64 with an error
• Clamps NaN/Inf values to lower bound instead of passing them through
• Checks the L1 sensitivity product for overflow in AddNoiseFloat64 before use
• Checks for int64 wrap in AddNoiseInt64 where silent overflow turns the product negative

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[miracvbasaran]

Thanks for the PR, Andy!

It seems we already skip NaN values for mean, variance, standard deviation, quantiles, and count & select partitions (indirectly, because their Increment() function does not take any input parameters). So, this should only affect BoundedSumFloat64's Add(e) function. I think it'd be simpler to add a "skip if value is NaN" check to Sum instead of modifying the Clamp function.

Re: L1 sensitivity overflow in laplace_noise.go, L0 & LInf are guaranteed to be a number (see checkArgsLaplace), so I think it'd suffice to verify there were no overflows during the L0 * LInf multiplication.