[HN Gopher] Meta built large-scale cryptographic monitoring
___________________________________________________________________
Meta built large-scale cryptographic monitoring
Author : kiyanwang
Score : 31 points
Date : 2024-12-02 06:53 UTC (2 days ago)
(HTM) web link (engineering.fb.com)
(TXT) w3m dump (engineering.fb.com)
| cactusplant7374 wrote:
| > Since there is a limit to how much data a symmetric
| cryptographic key can protect
|
| Is this regulatory related or self imposed?
| tptacek wrote:
| Neither: it's because (overgeneralizing) there are bounds on
| the number of times nonces can be generated under a key without
| risk of collision, which in AEAD constructions is a devastating
| event.
| philipwhiuk wrote:
| Is that a practical problem? If you generate enough you
| _will_ collide with someone but the end user is not going to
| know who the collision is with or that it happened.
| smitelli wrote:
| Scribe[1], Scuba[2], Hive[3], and folly[4]. It's neat for sure,
| but speaking as an outsider without the resources to learn (much
| less create!) an entire universe of data infrastructure and SDKs,
| it feels like I'm in the corner eating dinner at the kids' table.
|
| At any rate, I'm glad somebody out there is doing this stuff.
|
| [1]: https://engineering.fb.com/2019/10/07/core-infra/scribe/
|
| [2]: https://research.facebook.com/publications/scuba-diving-
| into...
|
| [3]: https://research.facebook.com/publications/hive-a-
| warehousin...
|
| [4]: https://github.com/facebook/folly/tree/main
| philipwhiuk wrote:
| Contrary to tptacek I feel like it's more likely that this about
| being able to retire weaker invocations and migrate people to
| stronger primitives and algorithms.
|
| Much like deprecating and retiring any other API.
|
| For example this allows them to report to upstream management:
|
| "We see 99% adoption of AES-GCM in favour of ChaCha20-Poly1305"
___________________________________________________________________
(page generated 2024-12-04 23:00 UTC)