Package: opaque
libopaque Python bindingsThese bindings provide access to libopaque which implements theIRTF CFRG RFC draftor you can read theoriginal paper.DependenciesThese bindings depend on the following:libopaque:https://github.com/stef/libopaque/libsodiumpysodiumAPIThere is one data structure that is used by libopaque:IdsThe 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 registration1-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)pwdUis the user's password.idsis anIdsstruct that contains the IDs of the user and the server.skSis an optional server long-term private-key4-step registrationRegistration 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)pwdUis the user's password.The user should hold on tosecUsecurely until step 3 of the registration process.Mneeds to be passed to the server running step 2.Step 2: The server responds to the registration request.secS,pub=opaque.CreateRegistrationResponse(M,skS)Mcomes from the user running the previous step.skSis an optional server long-term private-keyThe server should hold ontosecSsecurely until step 4 of the registration process.pubshould 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)secUcontains sensitive data and should be disposed securely after usage in this step.pubcomes from the server running the previous step.idsis anIdsstruct that contains the IDs of the user and the server.rec0should be passed to the server running step 4.export_keyis 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)rec0comes from the user running the previous step.secScontains sensitive data and should be disposed securely after usage in this step.rec1should be stored by the server associated with the ID of the user.Important Note: Confusingly this function is calledStoreUserRecord, 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 sessionAfter 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)pwdUis the user's password.The user should hold ontosecUsecurely until step 3 of the protocol.pubneeds 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)pubcomes from the user running the previous step.recis the user's record stored by the server at the end of the registration protocol.idsis anIdsstruct that contains the IDs of the user and the server.contextis a string distinguishing this instantiation of the protocol from others, e.g. "MyApp-v0.2"respneeds to be passed to the user running step 3.skis a shared secret, the result of the AKE.The server should hold ontosecSsecurely 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)respcomes from the server running the previous step.secUcontains sensitive data and should be disposed securely after usage in this step.contextis a string distinguishing this instantiation of the protocol from others, e.g. "MyApp-v0.2"skis a shared secret, the result of the AKE.authUis an authentication tag that can be passed in step 4 for explicit user authentication.export_keycan 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)secScontains sensitive data and should be disposed securely after usage in this step.authUcomes from the user running the previous step.