I am following the below steps to compute the HMAC using SHA1 algorithm using two different API and both the outputs are not matching.
1) I first compute HMAC for a given data and key using SHA1 algorithm through BouncyCastle API.
2) We compute HMAC for the data and key inside the HSM(Thales) using PKCS11 API(Pkcs11Interop).
When we compared the results of 1 and 2 the data does not match.
Bouncy Castle code:
HMAC hmac = HMACSHA1.Create();
String key = "BC55B4580589775F887890A7ACA5E624";
hmac.Key = Util.HexStringToByteArray(key);
byte[] modInput = Util.HexStringToByteArray("000000000000000000000006000080012b0601040181e438010102041603");
String ki = Util.ByteArrayToHexString(hmac.ComputeHash(modInput));
PKCS11 code:
ObjectHandle k = FindObjectByLabel(keyLabel);//same key as above
Mechanism m = new Mechanism(CKM.CKM_SHA_1_HMAC);
**//We have verified that both key and data value are the same**
return mSession.Connection.Sign(m, k, data);
Can anyone please help on this?
Related
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]))
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)
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?
The bitcoin wiki says this:
How to create Bitcoin Address
0 - Having a private ECDSA key
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
1 - Take the corresponding public key generated with it 0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
2 - Perform SHA-256 hashing on the public key
600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408
but when I run a sha256 on 0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
I don't get
600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408
What I get is
32511e82d56dcea68eb774094e25bab0f8bdd9bc1eca1ceeda38c7a43aceddce
what am I doing wrong?
Convert the hex string back to bytes and sha256 the bytes.
Something like that:
>>> hex_string = ('0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6')
>>> hex_data = hex_string.decode('hex')
>>> hashlib.sha256(hex_data).hexdigest()
'600ffe422b4e00731a59557a5cca46cc183944191006324a447bdb2d98d4b408'
I am trying to implement DHE_DSS into go's crypto/tls package. Unfortunately I can not seem to get the PreMasterSecret (Z) to be the same, my basic workflow is:
Receive Server Key Exchange Message
Extract P, G, Ys
Verify using the digital signature provided
Prepare Client Key Exchange Message
Create client's Xc
Generate Yc (Yc = G^Xc % P)
Generate Z (Z = Ys^Xc % P)
Send back Yc, packed like so:
ckx := make([]byte, len(yC)+2)
ckx[0] = byte(len(Yc)>>8)
ckx[1] = byte(len(Yc))
copy(ckx[2:], yBytes)
However, when I am debugging this with gnutls-serv the two PreMasterSecrets (Z) are different. Do I need to sign the returned Yc, or perhaps pack it in another way? I can not see anything in RFC 5246 to suggest this.
<-- EDIT -->
Here is a patch of my changes:
https://08766345559465695203.googlegroups.com/attach/48587532c74b4348/crypto.patch?part=4&view=1&vt=ANaJVrHbwydqEZc3zjUWqQ5C8Q5zEkWXZLdL0w6JJG3HYntOlBurUTY7mc9xR9OTfE0bJxs4eeL5a5SGd2jj9eIfXcwJQgLvJchXOgkYKBBynbPfshY8kuQ
Client key exchange will contain:
length (2 bytes) --> Y_C (in plain text)
I have implemented TLS in Java and I follow the same structure and works fine for me.
Do I need to sign the returned Yc?
No there is no need to sign the client DH public value, it is transferred in plain text.
You can take a pcap and check whether same values are being transferred in the packet. Also if GNU TLS has logger for printing the Y_C received, then you can check if proper data is being received.
If in case you still getting different Pre-Master secret then there seems to be some issue with the logic of generation of secret.