COVID-19 接触通知的目的是通知人们他们接触过后来病毒检测呈阳性的人。在此过程中保护隐私需要一些密码学，并避免用户位置的过于精细的细节。但是提供对疾病预防有用的数据需要在测量暴露时间时提供足够的细节。
Apple 和 Google 有一个用于此类曝光通知的新API，但它在 5 分钟和 10 分钟的数字之间存在紧张关系，我不知道如何解决。
加密规范v1.2.1 指定 10 分钟间隔作为哈希的输入：“在此协议中，时间以 10 分钟间隔离散化，从 Unix 纪元时间开始枚举。ENIntervalNumber 允许将当前时间转换为代表它所在区间的数字。”
同时，FAQ，v1.1，在输出中指定了 5 分钟的增量：“公共卫生当局将设置一起度过的时间的最小阈值，这样用户需要在蓝牙范围内至少 5 分钟才能注册匹配. 如果联系时间超过 5 分钟，系统会以 5 分钟为增量报告时间，最长可达 30 分钟，以确保隐私。
当间隔数仅每 10 分钟更新一次散列时，系统将如何以 5 分钟为增量报告时间？
虽然实际的 SDK 代码不可用，但我们可以有根据地猜测 ENIntervalNumber 不用于计算联系的持续时间。
让我们从加密退一步来描述一个人手机上实际发生的事情。这在此处记录，但要快速总结一下：
启用该应用程序的 Alice 每5 分钟扫描一次蓝牙广播采样。
效果最好的扫描策略是机会主义的（利用现有的唤醒和扫描窗口），并且每 5 分钟进行一次最少的定期采样。
也启用了该应用程序的 Bob 正在通过蓝牙广播包含其滚动接近标识符 (RPI) 的数据。
Alice 的手机检测到 Bob 的广播并保存 RPI 和元数据。该数据带有时间戳。
扫描结果应带有时间戳，并在每次广播时捕获 RSSI。
稍后，当 Bob 被诊断出一组他的 Temporary Key 和 ENInterval 号码时，将发送到诊断服务器，该服务器将此信息推送给所有客户端。
Alice 的手机接收此信息并计算 RPI 并与存储在她手机上的 RPI 进行匹配。在本地计算接触的距离和持续时间。
鉴于我们已经从 step3 获得了时间戳和 RPI，很可能通过简单地比较时间戳来完成持续时间的计算。这也将确保距离和持续时间数据不会泄露给服务器或其他客户端。