8 ms·
I don't think your #2 is a concern as OHTTP uses HPKE (https://blog.cloudflare.com/hybrid-public-key-encryption/ https://blog.cloudflare.com/hybrid-public-key-e
by jgrahamc 4y ago
I don't think your #2 is a concern as OHTTP uses HPKE (https://blog.cloudflare.com/hybrid-public-key-encryption/ https://blog.cloudflare.com/hybrid-public-key-encryption/).
- gostsamo 4y agoCorrect me if I'm wrong, but either the user encryption key is unique and hence the user is identifiable to Google, or a finite number of keys is used which makes the encrypted text subject to identification because a finite number of inputs can produce a given output. My cryptography education is rather superficial, so I might be missing something.
- jgrahamc 4y agoI know nothing about what has been implemented by Google/Fastly. All I can point you to is the details of Cloudflare's implementation and RFCs (which we co-authored): https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/ https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/
- skuhn 4y agoI can confirm that this is also the spec that we implemented at Fastly for this OHTTP relay service.
- kgraney 4y agoWe followed the same spec on the Google side (obviously). Our implementation of the request encapsulation/decapsulation for OHTTP is open sourced in Google Quiche. https://github.com/google/quiche/tree/main/quiche/oblivious_http https://github.com/google/quiche/tree/main/quiche/oblivious_...
- kgraney 4y agoCorrect. You can see exactly how we're constructing the messages here: https://source.chromium.org/chromium/chromium/src/+/main:services/network/oblivious_http_request_handler.cc https://source.chromium.org/chromium/chromium/src/+/main:ser... Note that in addition to normal HPKE we're also adding a Date header to the encrypted headers and padding the contents.