44 Matching Annotations
  1. Last 7 days
  2. Feb 2023
  3. Jan 2023
    1. We need to read the Signature header, split it into its parts (keyId, headers and signature), fetch the public key linked from keyId, create a comparison string from the plaintext headers we got in the same order as was given in the signature header, and then verify that string using the public key and the original signature.

      ```ruby require 'json' require 'http'

      post '/inbox' do signature_header = request.headers['Signature'].split(',').map do |pair| pair.split('=').map do |value| value.gsub(/\A"/, '').gsub(/"\z/, '') # "foo" -> foo end end.to_h

      key_id = signature_header['keyId'] headers = signature_header['headers'] signature = Base64.decode64(signature_header['signature'])

      actor = JSON.parse(HTTP.get(key_id).to_s) key = OpenSSL::PKey::RSA.new(actor['publicKey']['publicKeyPem'])

      comparison_string = headers.split(' ').map do |signed_header_name| if signed_header_name == '(request-target)' '(request-target): post /inbox' else "#{signed_header_name}: #{request.headers[signed_header_name.capitalize]}" end end

      if key.verify(OpenSSL::Digest::SHA256.new, signature, comparison_string) request.body.rewind INBOX << request.body.read [200, 'OK'] else [401, 'Request signature could not be verified'] end end ```

  4. Dec 2022
  5. Nov 2022
  6. Sep 2022
  7. Aug 2022
  8. Jul 2022
  9. Jun 2022
  10. Apr 2022
    1. The IETF provides an IMAP interface into the email list archives. This interface allows both anonymous and logged-in access.

      ``` Server: imap.ietf.org Port: 143 or 993

      For authenticated access use your datatracker login and password.

      For anonymous access use username="anonymous", and provide your email address as a password. ```

    1. IMAP subscriptions: An IMAP server with all IETF email list archives is available for IMAP access at imap.ietf.org:993.
  11. Mar 2022
  12. Dec 2020
    1. Q_plain

      Is the entropy from Q_plain really needed? A reason for it would be that the client provides randomness with the nonce contained in Q_plain, in the sense of a contributive key exchange. However, the client already contributes the HPKE ephemeral key.

      If the Extract step should stay, I suggest changing the order of Q_plain and odoh_secret. The value odoh_secret is of fixed size and uniformly random, and thus fits better as salt to HKDF-Extract. If the first value is longer than a hash function block size, HMAC will do an additional hashing step: This seems easily possible for Q_plain.

    2. proxy and target indistinguishability

      How is this defined?

    3. of unique per-client keys

      What kind of keys are meant here? Unique target public keys per client?

    4. Q_encrypted

      The function could receive only ct instead, as it does not use enc, and setup_query_context already splits Q_encrypted.

    5. key_id

      The function does not use this parameter.

    6. context

      The context is not returned by this function, but required as parameter to decrypt_response_body.

    7. Expand(Extract("", config), "odoh key id", Nh)

      config contains kem_id, kdf_id, aead_id, and the public key. Why is entropy extraction needed here?

  13. Nov 2019
  14. Oct 2018
  15. Mar 2018