Padding of diagnosis key upload messages (requestPadding) inconsistent/wrong

[PsikoBlock]

When uploading diagnosis keys, a padding value called requestPadding is added for plausible deniability purposes (to make it appear that there are always 14 or 15 keys in the uploaded message). I believe I have found a few issues with the way the length of this padding value is generated.

First, the algorithm in the Android app uses 15 keys as a value to pad to, while the iOS app uses 14. A comment in the iOS app states that "the nparameter is currently set to 0, but can change in the future when there will be support for 15 keys." It seems this change was made only for Android, but not for iOS.

Second, in both apps, the base value for key length is set to 28 bytes. My estimate of the key length however yields the following:

16 key_data
 1 transmission_risk_level
 4 rolling_start_interval_number
 2 rolling_period
 1 report_type
 1 days_since_onset_of_symptoms
 6 protobuf field keys
 2 field key + length for embedded TemporaryExposureKey message in upload message
--
33 total

Note that rolling_period can also be 1 byte long, but is 2 bytes for full days, which should be simulated as it is the normal use case. It seems as though the days_since_onset_of_symptoms, which is only present in GAEN v2, is not considered either as the value of 28 bytes was added before the transition to v2. The field key and length values prepended when adding additional keys in the upload message also seem to be ignored. In my eyes, the estimated key length should be 33 bytes on both platforms.

The relevant code is found here for iOS and here for Android.

[Ein-Tim]

@dsarkar Please mirror this issue to JIRA. It is nearly one year old and there was no feedback here at all.