What am I doing wrong in the following code where I'm trying to achieve asymmetric signing and encryption using jose-python? - cryptography

from jose import jws
from jose import jwe
with open('privkey.pem', mode='r') as privatefile:
privkey = privatefile.read()
with open('pubkey.pem', mode='r') as pubfile:
pubkey = pubfile.read()
####################################
## Signing request with private key
####################################
query = {
"QueryType": 1,
"QuerySubType": None
}
signed = jws.sign(query, privkey, algorithm='RS256')
print(signed)
# verify = jws.verify(signed, pubkey, algorithms=['RS256'])
# print(verify)
################################
## Encryption
################
encrypted = jwe.encrypt(signed, pubkey, algorithm='RSA_OAEP', encryption='A256CBC_HS512')
print(encrypted)
I created rsa key pair of size 2048.
The singing and verification works fine.
I am getting en error "jose.exceptions.JWEError: Algorithm RSA_OAEP not supported". I've tried all the algorithms and encryption, but getting the same error for algorithms not supported for all of them.
What am I doing wrong here?

The key management and the content encryption algorithms are specified wrongly. Use hyphens instead of underscores:
encrypted = jwe.encrypt(signed, pubkey, algorithm='RSA-OAEP', encryption='A256CBC-HS512')
However, it is more robust to apply the provided constants defined in the class jose.constants.Algorithms:
from jose.constants import Algorithms
...
encrypted = jwe.encrypt(signed, pubkey, algorithm=Algorithms.RSA_OAEP, encryption=Algorithms.A256CBC_HS512)

Related

ed25519 secret to public key

I am trying to use the python code given + test vector 2 given by rfc
https://www.rfc-editor.org/rfc/rfc8032#section-7.1
expected results
secret_to_public()
SecretKey = 4ccd089b28ff96da9db6c346ec114e0f
PublicKey = 3d4017c3e843895a92b70aa74d1b7ebc
my result
secret_to_public()
SecretKey = 4ccd089b28ff96da9db6c346ec114e0f
PublicKey = 4e15...56d7
my concerns
Am I using the right secret key ?
They seem to show a 64 byte secret key but ed25519 uses a 32 byte secret key.
Am I encoding the secret key / decoding the result correctly ?
code
#https://www.rfc-editor.org/rfc/rfc8032#section-7.1
sK = b"4ccd089b28ff96da9db6c346ec114e0f"
print(sK)
print(len(sK))
for i in range(32):
print(hex(secret_to_public(sK)[i]))
Python Gist :
https://gist.github.com/redazul/668ca5d8501e73509a55777f5c84e469
Taken from https://www.rfc-editor.org/rfc/rfc8032#section-6
Thanks #Topaco
#https://www.rfc-editor.org/rfc/rfc8032#section-7.1
sK=bytes.fromhex("4ccd089b28ff96da9db6c346ec114e0f5b8a319f35aba624da8cf6ed4fb8a6fb")
print(sK)
print(len(sK))
for i in range(32):
print(hex(secret_to_public(sK)[i]))

Padding mode not valid when try do decrypt a JWE payload with RSA-OAEP-256 and A256GCM

I have no expertise with cryptography, i'm trying to decrypt a JWE payload in ASP.net core C#, the information that i have is the encryption was performed with RSA-OAEP-256 and A256GCM, so i'm using Jose libraries do deal with cryptography, the code is like:
eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0.rb3as5DV3PjfYM9cmxO1uE_OaLBt_gFMG9oe1iW_8999KNXEcxAuENaAJgD0fIWdrYD0UwDfkPxzG2cKy3SkvhQE5af7HNDuJBK7p_jjWZMNxtLO3IWCVbcYmH8r-TJEf4MPrDQi_0wP0QLIqH9aR3EVzRdkZ0tn1f8uSsaRlv7rXX_09mPME8V3y7dIDVAKJ0upvJvuyjnsNuAxXVAKvXjNdesKE_GMc3P5ZH6tOBb78a3uLyTOVf-itdR0f2Y7932QPnWbOM1d45mYARUK8Q28IHlKnyhntkA9YP8HQfvFdyMnAKhzPiybSU3Hg1U6wOh6qeYOqN4IIUedzZz__HFZZLpfPJHUacEXfgOWlPO3ZryMxN9v13pDG223oHl-9zbCOdtNsU3igOWlDM4094MECfpYWWem9cuEnbADjsyqVaq0l3CoL8MLUvDKpEjgI7ezopX0UFOlTWXjDxK-EmWeHOJlUAOjRJKUtmJBhiqtjY4quWsTO5xRzX-_fPyFw2Cql2T2_03FDNgZY6u8GpvmBR3f9E1jXqzNI36vbIdtBa6l0tksOPBnLeG070boMdViKMdUxAjzCW1EcUvaXo_vgOZ-ZU8_loOvGBOYmzE6myesQCMDaHXrSJROoR-G5lk5OO-hED6KWUptkqKI5vAuAHGuojq0_1d2YT4X4e8._jpZ8zc1XWIEFVmu.TKbdl02R_2q6-QwtW4cnUiNDoXhFX_fkTDxrhxofM8BhLTMhMk1cx3jvSPJADftBd5NgHghOouZePw_NwapFpNUwgFq__QvPVKcw6QQwU1IKcuh-ShfSJRtr9oVC93zQprZSvgLJsf5K-46sbjnEBc6dzCsL07r3M9fbg4XwaJyRW7iriLTXFbFEd-CbsqlGgZupHGUbn0W_h5PVYTuwAp4I7wyp_k2xF0i9MQRcLk04fm--zdwYo7-FfM3yfsz129OXzpH7tp6c_dl-5D53_cleLFLAIn1BNnDwVFfKIPkjbjz8_NzGoXWWESW8DP00Z2Of4qVgdhtBWunduriM7NyDWaiDWgePt3qX0A3nvSp6bIp9sXdZYiuGVM3z7-iMb-oJPsj1Abx5MuRHpbvovNLHY89QnV8Qf43TCUOGxpgiNcULd4QxeLn2NmXcmbxlFVxhGHxq44XHF0A14dEiWSYp4001T7lun-yv3DPZuiGiO-L4iKHZT-gnHAzjaDIyXVo5JsL1qWGVi59DJneQrnyjodZs7ESCUIbOASJ5SJ9QtSOu-uyvKVdyK6Tfw9-cGNXAzDBAOBmHcnxMOtWcZ6AscDJhpI_2quoktpTD9GkEM0gItKZ5W3r99i8t_RoZCakBdBY6D5gwVg4yFsJyb1YvqsYsH1X8MQBPdrVBTc4DUT0M0ucpfl5bV3nlMxxEffCyk-jbNNXid9_kOjq4Xv3-pHO4qJUQpJvRYIvGqyC0Ep1swo3-gbsUIjtEfyLlf2JkcDIM5WkV_iSvEbjch9lceTMKzjQVZgMnDWPvTtEvAZCXUxbRu9wE9fuX9F2W-yJ_DyB0o871IOhdDi0VyQcipQ2wkvuZecu9uqLFGtVk5NaPxYq0uOyaDQ3QzDwucAMwalaXPua9qjhLjM6TCePgn_ncVdN5jckMXo--RRAX3o4G1Hm8_xcJ6Amcvl8vsb7hUTdXY6um6CT-WDHbi-FQgMyyn-vlC64NJdngvT3uWvcKETS8UoKhp78nFDy20qWXIqSzxwi7rf60OL7vPZ_6McVfXORTbMjxvGRTT5skgkY58B5VPvB1c6vN12tKN3E3lqbJCpzass0rSzbfBxdRDg-PIV-Nuv0S-ch9aUxA5h6cMrYBZMQuiV-RO3EoqfQSU0JNGJuGir8mQAKuI5pJwROKrn1cCAaTSrcueobXz_ppJgZdxzjh_dUzZhfUrrE7DqJgPqHbuEPju7ViB39iPLsiniDz3W1iOhQKSbFDNzLmG_yzjKv1jF90onqIyo_mLN3kVlxHyvgP4MA8405OJCR_Cqmob0djhkiRsJCfNWUuVmmq0q0YPTfFIAn_R9A9Zdlwd8Ybg88_RKegLMwySgvfWT27w2OwGMQX6kCrPxV5pWS57lgmPiflq-R1H1uHXvBDoXySx3Uzv1J2ElzvtQGVufZFBznnirsQI87cwxSz76gWiVelf4GNJzRme3O1XRPhmlMlTBWCHOASRxTo9mM964oHc5g3cIRWrzNFppTV_FkJQ6cwPFYYjFdSA3Hh1w8_RxCxyXncsunAZoniCgV6KEBN7A5KybKMu424JQqWqdlKQqHBW7XLdqMnMH-ryzie22fGmIn4RrT5ha6ZI43rvLREt_4dYJJpmh4yw1f7Bh-8mIuKd1ha3lERWP0qZhSR6sSsCHob_UTe4JW_KwVT0om4FAgMzbLoKoZf1v01QHHn0ISSH9cvtgwv8TObcleMkEYrDJ_MxsSxOKm-B7VoKFDEhtns0ybZA_QYEK40voAzhrGO4CPjsOR7tWKIUFk3veNJRxmixBeGVP7Up7KAvXk7wAhRg060MzZ0Gf4kaWi6IS-H_hWSPYbb0NO0IQRcGYFXALt58p0hO61HpUqG5gnQGiceiMnj1DVKIVAbtnUhB_rGcrePPCKT_TQIeCyO4FRjtHw73iYePZgacVEJDGOqthPlVWJpKF9IWeUu5Ngqc3j6L75bQ4uuvUGVHAORbH3bzXoxxqx4hjU2kI0KvQwGs0VC6rCCgC2GCqJmn3-W0jxir9Mw3VBMaBOOpslv-FSMLriL4UX1solBR3pZ7bCm1vGCUooaj9tG0Pp4n6dwqGz54hkJ5vgYX5xEKZMYYJxhhKomRFNzvhJtli9qe4lNLUsMHEnwcs-BX1tMi7JSOxmPm5BNT_A7qYeRj4dJh4cR926geYdQpcXHhYC9qyNXuqsLG5Qf88rPqMeQerwBmxcwGbTUh2eUpSu4dZZzWuCUiG92Fb55UBtElxZ0mDsQ6SPso6g44oaBNaBbOJ1DnigSE6n1X-yz2HyRjYKHLCpbSHz2xDpQaHSUMVuHphOlS69Wn0Mwb_HljnQU0S34HJya1-zivBIDepkmt3_9EhLy3La872n3H1IEzkaNX7cjCr77imU2lQ32G1iwbFAo4FvJfkJhYwP2xLh1Q38GeE_2vsiQlu1iFr3Fs_Wxv-hYW6rnAz1B_1MSOI0slWMQywIhqZ7dbyyWv_S-oxecVneZ4LlSW-hxCYJGtrsGJtnEaRHVYZJ-N-MjwBm9nJU4P8mY9Nz9MPbWbovb8gJ5DLXFppZjReRk2A2zHTGKzav6Q0DYKI0NGmSDHJW6UbSjVzBBJe2r85NS4u5HGS_wyEhXXnMtJZdn6VBQj9AEY4Jrt2xZzCRoqWlUI46uMObvWq5qvkKCPcSLKyrHEIigbR3JmW3zzDNvc39RmiC6cbJ0Ypb-G0D4CNwdV2bemLzs29NIWms75cqMHxlkyKOqEX5UsYlGBhra_kM.vykYzq6TQ8ApQdyREGo6-g
var jwtSettings = new JwtSettings();
jwtSettings.RegisterMapper(new JwtPayloadConverter.JsonMapperJwt());
var decodedJwt = Jose.JWT.Decode(paylaodRetornoStone2, rsa, Jose.JweAlgorithm.RSA_OAEP_256, Jose.JweEncryption.A256GCM, jwtSettings);
when i try do decrypt the payload, i'm getting this error: specified padding mode is not valid for this algorithm.
the specific part of code that is throwing this exception is the:
byte[] cek = keyManagement.Unwrap(encryptedCek, key, jweAlgorithm.KeySize, header);
the implementation of RsaOaep256KeyManagement is doing this:
return Ensure.Type<RSA>(key, "RsaKeyManagement algorithm expects key to be of RSA type.").Decrypt(encryptedCek, RSAEncryptionPadding.OaepSHA256);
it seens that paddind mode is right, anyone have an idea to how fix this error?

Verify user identity on my site, using SSL Certificates

I need to register companies on my site for an electronic procurement system. Up to now these were local companies I could meet physically and give credentials to, but now they can be companies based anywhere in the world.
The solution is to have an online registration process whereby they submit a third party certificate. So say Verisign says they are 'Company X' so I register them as Company X and issue them credentials.
How can I implement this on my site? Do I simply give them a field in the registration form where they upload their certificate file? Do I then manually check these certificates in my back office? How does one check this manually? Is there a way to automate this process?
Once they have an account, should I simply request the credentials I issue them with to log in, or can all future logins request the same certificate file? In these a particular format for certificates I can request or should I allow a number of common formats that different certificate vendors provide?
Thanks in advance.
Being able to provide a certificate does unfortunately not prove anything. A certificate is completely public, and anyone can get a hold of the SSL certificate for any website. The certificate contains a public key. Proving ownership of the corresponding private key is what's required.
This is possible to do, but it requires that your users are technical enough to know how to run scripts and/or OpenSSL terminal commands so that they can sign something with their private key. Having the users upload their private key is of course a big no-no, as it means you can now act as the user, and that would require an enormous amount of trust in you to discard the private key after you've verified it.
From a technical perspective, you can do the verification by creating some kind of challenge, for example a random string, and have the user encrypt this string with their private key. If you decrypt this string with the public key in the certificate, and get the original string back, then you know that they have possession of the corresponding private key.
Here's a self-contained Ruby script that demonstrates this, with comments indicating which part of it is run on your side, and which part is run on their side.
require "openssl"
## This happens on the client side. They generate a private key and a certificate.
## This particular certificate is not signed by a CA - it is assumed that a CA
## signature check is already done elsewhere on the user cert.
user_keypair = OpenSSL::PKey::RSA.new(2048)
user_cert = OpenSSL::X509::Certificate.new
user_cert.not_before = Time.now
user_cert.subject = OpenSSL::X509::Name.new([
["C", "NO"],
["ST", "Oslo"],
["L", "Oslo"],
["CN", "August Lilleaas"]
])
user_cert.issuer = user_cert.subject
user_cert.not_after = Time.now + 1000000000 # 40 or so years
user_cert.public_key = user_keypair.public_key
user_cert.sign(user_keypair, OpenSSL::Digest::SHA256.new)
File.open("/tmp/user-cert.crt", "w+") do |f|
f.write user_cert.to_pem
end
## This happens on your side - generate a random phrase, and agree on a digest algorithm
random_phrase = "A small brown fox"
digest = OpenSSL::Digest::SHA256.new
## The client signs (encrypts a cheksum) the random phrase
signature = user_keypair.sign(digest, random_phrase)
## On your side, verify the signature using the user's certificate.
your_user_cert = OpenSSL::X509::Certificate.new(File.new("/tmp/user-cert.crt"))
puts your_user_cert.public_key.verify(digest, signature, random_phrase + "altered")
# => falase
puts your_user_cert.public_key.verify(digest, signature, random_phrase)
# => true
## On your side - attempting to verify with another public key/keypair fails
malicious_keypair = OpenSSL::PKey::RSA.new(2048)
puts malicious_keypair.public_key.verify(digest, signature, random_phrase)
Note that this script does not take into account the CA verification step - you also obviously want to verify that the user's certificate is verified by a CA, such as Verisign that you mentioned, because anyone can issue a certificate and hold a private key for foo.com - it's the CA signature of the certificate that provides authenticity guarantees.

How to calculate and insert signatures in a X509 Certificate

I'm trying to perform the fingerprint of a TBSCertificate in order to sign it and insert it in a x509 certificate. I can't find any tool or library that allow me to do it separately.
I can create a x509 certificate and perform the signature like with openssl or many libraries but it will be included directly into the certificate, and I need to modify the signature before including it.
Do you know anyone?
I finally managed to do it using the pyasn1 library for python.
In case someone need it in the future, here you have a conversation in the pyasn1 mailing talking about it:
https://sourceforge.net/p/pyasn1/mailman/message/34523982/
and my personal solution:
from M2Crypto import X509, EC, EVP
from hashlib import sha256
from pyasn1_modules.rfc2314 import Signature
from pyasn1_modules.rfc2459 import Certificate
from pyasn1.codec.der import encoder, decoder
csr = "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNyakNDQVpZQ0FRQXdEUVlKS29aSWh2Y05BUUVMQlFBd2dZWXhDekFKQmdOVkJBWVRBa05VTVJJd0VBWUQKVlFRSURBbENZWEpqWld4dmJtRXhFekFSQmdOVkJBY01Da0psYkd4aGRHVnljbUV4RVRBUEJnTlZCQW9NQ0ZCaAplVk5sYm5ObE1Rd3dDZ1lEVlFRTERBTkJRMEV4RERBS0JnTlZCQU1NQTBGRFFURWZNQjBHQ1NxR1NJYjNEUUVKCkFSWVFZV05oUUdSbGFXTXVkV0ZpTG1OaGREQWVGdzB4TlRFd01EZ3dPVFF4TURKYUZ3MHhOakV3TURjd09UUXgKTURKYU1JR0FNUXN3Q1FZRFZRUUdFd0pEVkRFU01CQUdBMVVFQ0F3SlFtRnlZMlZzYjI1aE1STXdFUVlEVlFRSApEQXBDWld4c1lYUmxjbkpoTVF3d0NnWURWUVFLREFOVlFVSXhEVEFMQmdOVkJBc01CRVJGU1VNeEt6QXBCZ05WCkJBTU1JbTF0VjFGVlFsbFpWMVJ2V2xwTmNIYzBjR0ZXVG5NeVRXNXZTbE5oUlZkUmVua3dWakFRQmdjcWhrak8KUFFJQkJnVXJnUVFBQ2dOQ0FBUjVJTWU2aDJwUlpwM201b25VcWloeGwyNkFIQjhMR01WZCtMWUNFTUl4V2U1ZQpySVJmcDA5bHNPUjB3L1B3T3N0bzRXSWFYOXFPSnBTb2JwZFlYRnJaTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCCkFRQXdHZVl3bkM5MmErR1g3VXE4N1k5Z3hXdFVKUWZiUlRwbXdCV1NPdmNlS3Z2Ky9zV3o5VFRqSGRKbElqVnYKbkQ5RHY5aHVlQUVONkE3Sm43SE80ZDhwelJ2d3pQSU5peXN4TUlzaWsxbldpTTRieTBLSDh4bE5SZEFoc3ZZTApVQ3hLSXVGMm1sUytJRGVtMUQyZE96L3ZFZlcrZVE4NVhsSVRycExpMFZlY3d5NnhwejNMN2R2SEdTOFJ1aVlyCkxkS1J3VnVGYmI4QmRHdVJ3dHgwNCtEeGJFKzlUb3hHSmFiM1VaV1loV3ByekcyS2owV0pORW44UlBwWXJjb2sKY3lBSTh4OFh0TDUrZUs5aklpV1NlcHIzcU9Zc3V6V2NqZ2VIeUdCUHNqN1lRQ2ZuWVFTbHBJMzJHRnZ5YWRmTApmRmZXSExxZE9nQmVET2JwenlaVDlyazkKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=="
cert = X509.load_cert_string(b64decode(csr))
ca_pkey = EVP.load_key(ACA_KEY)
asn1_cert = decoder.decode(cert.as_der(), asn1Spec=Certificate())[0]
tbs = asn1_cert.getComponentByName("tbsCertificate")
tbs_der = encoder.encode(tbs)
digest = sha256()
digest.update(tbs_der)
signature = ca_pkey.get_rsa().sign(digest.digest(), "sha256")
# Take the raw signature and turn it into a BitString representations (special thanks to Alex <ralienpp#gmail.com>)
bin_signature = Signature("'%s'H" % ''.join("%02X" % ord(c) for c in signature))
asn1_cert.setComponentByName("signatureValue", bin_signature)
# Check that both certificates matches
cert.sign(ca_pkey, md='sha256')
print cert.as_text()
print encoder.encode(asn1_cert) == cert.as_der()
The initial csr is a base64 encoded X509 Certificate in BER.
Is important to stress the csr already contains the proper Signature Algorithm.

XMPP SASL SCRAM-SHA1 Authentication

Recently, I was able to get MD5 authentication working for XMPP streams in Swift IOS following the instructions on the following two websites (I used the CC-MD5 function of Apple's CommonCrypto C library for the actual hashing):
http://wiki.xmpp.org/web/SASLandDIGEST-MD5
http://www.deusty.com/2007/09/example-please.html
I'm searching for a similar explanation for how to get other hashed SASL authentication schemes working, especially SCRAM-SHA1. I have found the official RFC5802 document but I'm having a lot of trouble understanding it (it is not specific to XMPP either). I would appreciate a simpler explanation or some simple readable code (C, PHP, C++, Javascript, Java) specific to XMPP authentication that doesn't use libraries for anything other than the actual hashing.
I'm interested in understanding the process and am not looking to use the ios XMPP-Framework. Any help would be appreciated.
SCRAM-SHA-1
The basic overview of how this mechanism works is:
The client sends the username it wants to authenticate as.
The server sends back the salt for that user and the number of iterations (either by generating them or looking them up in its database for the given username).
The client hashes the password with the given salt for the given number of iterations.
The client sends the result back.
The server does a variation of the hashing and sends it result back to the client, so the client can also verify that the server had the password/a hash of the password.
The cryptographic algorithms you'll need are SHA-1, HMAC with SHA-1 and PBKDF2 with SHA-1. You should look up how to use them in your language/framework, as I don't recommend implementing them from scratch.
In detail
First normalize the password (using SASLprep), this will be normalizedPassword. This is to ensure the UTF8 encoding can't contain variations of the same password.
Pick a random string (for example 32 hex encoded bytes). This will be clientNonce.
The initialMessage is "n=" .. username .. ",r=" .. clientNonce (I'm using .. for string concatenation).
The client prepends the GS2 header ("n,,") to the initialMessage and base64-encodes the result. It sends this as its first message:
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="SCRAM-SHA-1">
biwsbj1yb21lbyxyPTZkNDQyYjVkOWU1MWE3NDBmMzY5ZTNkY2VjZjMxNzhl
</auth>
The server responds with a challenge. The data of the challenge is base64 encoded:
<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
cj02ZDQ0MmI1ZDllNTFhNzQwZjM2OWUzZGNlY2YzMTc4ZWMxMmIzOTg1YmJkNGE4ZTZmODE0YjQyMmFiNzY2NTczLHM9UVNYQ1IrUTZzZWs4YmY5MixpPTQwOTY=
</challenge>
The client base64 decodes it:
r=6d442b5d9e51a740f369e3dcecf3178ec12b3985bbd4a8e6f814b422ab766573,s=QSXCR+Q6sek8bf92,i=4096
The client parses this:
r= This is the serverNonce. The client MUST ensure that it starts with the clientNonce it sent in its initial message.
s= This is the salt, base64 encoded (yes, this is base64-encoded twice!)
i= This is the number of iterations, i.
The client computes:
clientFinalMessageBare = "c=biws,r=" .. serverNonce
saltedPassword = PBKDF2-SHA-1(normalizedPassword, salt, i)
clientKey = HMAC-SHA-1(saltedPassword, "Client Key")
storedKey = SHA-1(clientKey)
authMessage = initialMessage .. "," .. serverFirstMessage .. "," .. clientFinalMessageBare
clientSignature = HMAC-SHA-1(storedKey, authMessage)
clientProof = clientKey XOR clientSignature
serverKey = HMAC-SHA-1(saltedPassword, "Server Key")
serverSignature = HMAC-SHA-1(serverKey, authMessage)
clientFinalMessage = clientFinalMessageBare .. ",p=" .. base64(clientProof)
The client base64 encodes the clientFinalMessage and sends it as a response:
<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
Yz1iaXdzLHI9NmQ0NDJiNWQ5ZTUxYTc0MGYzNjllM2RjZWNmMzE3OGVjMTJiMzk4NWJiZDRhOGU2ZjgxNGI0MjJhYjc2NjU3MyxwPXlxbTcyWWxmc2hFTmpQUjFYeGFucG5IUVA4bz0=
</response>
If everything went well, you'll get a <success> response from the server:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
</success>
Base64 decoded this contains:
v=pNNDFVEQxuXxCoSEiW8GEZ+1RSo=
The client MUST make sure the value of v is the base64 encoding of the serverSignature.
Extras
This is the basic version of the algorithm. You can extend it to do:
Channel binding. This mixes in some information from the TLS connection to the procedure to prevent MitM attacks.
Hashed storage. If the server always sends the same salt and i values, then the client can store only saltedPassword instead of the user's password. This is more secure (as the client doesn't need to store the password, just a hard to reverse salted hash) and faster, as the client doesn't need to do all the key stretching every time.
The server can also use hashed storage: the server can store only salt, i, storedKey and serverKey. More info on that here.
Possibly, also adding SCRAM-SHA-256 (though server support seems non-existent).
Pitfalls
Some common pitfalls:
Don't assume anything about the length of the nonces or salt (though if you generate them, make sure they are long enough and cryptographically random).
The salt is base64 encoded and can contain any data (embedded NULs).
Not using SASLprep may work fine for people using ASCII passwords, but it may completely break logging in for people using other scripts.
The initialMessage part of the authMessage does not include the GS2 header (in most situations, this is "n,,").
Test vectors
If you want to test your implementation, here are all the intermediate results for the example from the RFC:
Username: user
Password: pencil
Client generates the random nonce fyko+d2lbbFgONRv9qkxdawL
Initial message: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
Server generates the random nonce 3rfcNHYJY1ZVvWVs7j
Server replies: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096
The salt (hex): 4125c247e43ab1e93c6dff76
Client final message bare: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
Salted password (hex): 1d96ee3a529b5a5f9e47c01f229a2cb8a6e15f7d
Client key (hex): e234c47bf6c36696dd6d852b99aaa2ba26555728
Stored key (hex): e9d94660c39d65c38fbad91c358f14da0eef2bd6
Auth message: n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
Client signature (hex): 5d7138c486b0bfabdf49e3e2da8bd6e5c79db613
Client proof (hex): bf45fcbf7073d93d022466c94321745fe1c8e13b
Server key (hex): 0fe09258b3ac852ba502cc62ba903eaacdbf7d31
Server signature (hex): ae617da6a57c4bbb2e0286568dae1d251905b0a4
Client final message: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
Server final message: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Server's server signature (hex): ae617da6a57c4bbb2e0286568dae1d251905b0a4