Skip to main content

python libopaque wrapper

Project description

libopaque Python bindings

These bindings provide access to libopaque which implements the IRTF CFRG RFC draft or you can read the original paper.

Dependencies

These bindings depend on the following:

API

There is one data structure that is used by libopaque:

Ids

The IDs of the peers are passed around as a struct:

# wrap the IDs into an opaque.Ids struct:
ids=opaque.Ids("user", "server")

1-step registration

1-step registration is only specified in the original paper. It is not specified by the IRTF CFRG draft. 1-step registration has the benefit that the supplied password (pwdU) can be checked on the server for password rules (e.g., occurrence in common password lists). It has the drawback that the password is exposed to the server.

rec, export_key = opaque.Register(pwdU, ids, skS)
  • pwdU is the user's password.
  • ids is an Ids struct that contains the IDs of the user and the server.
  • skS is an optional server long-term private-key

4-step registration

Registration as specified in the IRTF CFRG draft consists of the following 4 steps:

Step 1: The user creates a registration request.

secU, M = opaque.CreateRegistrationRequest(pwdU)
  • pwdU is the user's password.

The user should hold on to secU securely until step 3 of the registration process. M needs to be passed to the server running step 2.

Step 2: The server responds to the registration request.

secS, pub = opaque.CreateRegistrationResponse(M, skS)
  • M comes from the user running the previous step.
  • skS is an optional server long-term private-key

The server should hold onto secS securely until step 4 of the registration process. pub should be passed to the user running step 3.

Step 3: The user finalizes the registration using the response from the server.

rec0, export_key = opaque.FinalizeRequest(secU, pub, ids)
  • secU contains sensitive data and should be disposed securely after usage in this step.

  • pub comes from the server running the previous step.

  • ids is an Ids struct that contains the IDs of the user and the server.

  • rec0 should be passed to the server running step 4.

  • export_key is an extra secret that can be used to encrypt additional data that you might want to store on the server next to your record.

Step 4: The server finalizes the user's record.

rec1 = opaque.StoreUserRecord(secS, rec0)
  • rec0 comes from the user running the previous step.

  • secS contains sensitive data and should be disposed securely after usage in this step.

  • rec1 should be stored by the server associated with the ID of the user.

Important Note: Confusingly this function is called StoreUserRecord, yet it does not do any storage. How you want to store the record (rec1) is up to the implementor using this API.

Establishing an opaque session

After a user has registered with a server, the user can initiate the AKE and thus request its credentials in the following 3(+1)-step protocol:

Step 1: The user initiates a credential request.

pub, secU = opaque.CreateCredentialRequest(pwdU)
  • pwdU is the user's password.

The user should hold onto secU securely until step 3 of the protocol. pub needs to be passed to the server running step 2.

Step 2: The server responds to the credential request.

resp, sk, secS = opaque.CreateCredentialResponse(pub, rec, ids, context)
  • pub comes from the user running the previous step.

  • rec is the user's record stored by the server at the end of the registration protocol.

  • ids is an Ids struct that contains the IDs of the user and the server.

  • context is a string distinguishing this instantiation of the protocol from others, e.g. "MyApp-v0.2"

  • resp needs to be passed to the user running step 3.

  • sk is a shared secret, the result of the AKE.

  • The server should hold onto secS securely until the optional step 4 of the protocol, if needed. otherwise this value should be discarded securely.

Step 3: The user recovers its credentials from the server's response.

sk, authU, export_key = opaque.RecoverCredentials(resp, secU, ctx, ids)
  • resp comes from the server running the previous step.

  • secU contains sensitive data and should be disposed securely after usage in this step.

  • context is a string distinguishing this instantiation of the protocol from others, e.g. "MyApp-v0.2"

  • sk is a shared secret, the result of the AKE.

  • authU is an authentication tag that can be passed in step 4 for explicit user authentication.

  • export_key can be used to decrypt additional data stored by the server.

Step 4 (Optional): The server authenticates the user.

This step is only needed if there is no encrypted channel setup towards the server using the shared secret.

opaque.UserAuth(secS, authU)
  • secS contains sensitive data and should be disposed securely after usage in this step.
  • authU comes from the user running the previous step.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

opaque-0.2.0.tar.gz (10.1 kB view details)

Uploaded Source

File details

Details for the file opaque-0.2.0.tar.gz.

File metadata

  • Download URL: opaque-0.2.0.tar.gz
  • Upload date:
  • Size: 10.1 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/3.4.2 importlib_metadata/4.6.1 pkginfo/1.7.1 requests/2.26.0 requests-toolbelt/0.9.1 tqdm/4.61.2 CPython/3.9.7

File hashes

Hashes for opaque-0.2.0.tar.gz
Algorithm Hash digest
SHA256 333e25424d4ba990d79643dcbda220850d80d3f6f8fd53f5866fcc040d474693
MD5 9f8f5241953ef3faa1903b100c5af7e5
BLAKE2b-256 82a960461141aa12bb03948d00e002ad4d6a9842a48f579f02428571cf0967c9

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page