I have just implemented an AES-128 encryption algorithm, with the following message and key.
Message: "Two One Nine Two" (128 bits)
Key: "Thats my Kung Fu" (128 bits)
The cipher output for this is :
29c3505f571420f6402299b31a02d73a
which is correct when I cross-checked with online generators.
However, the online generator output is usually longer :
29c3505f571420f6402299b31a02d73ab3e46f11ba8d2b97c18769449a89e868
I tried several padding methods (bit, zerolength, cms, null, space) but nothing seems to produce exactly the b3e46f11ba8d2b97c18769449a89e868 part of the crypt text.
Could anyone help to explain what padding method (in binary) is used to produce those numbers, please?
Thank you #Topaco, the padding is indeed PKCS7. In this case, since the input is exactly 128 bit, an extra padding block of 128 bit must be appended, consisting of 16 bytes of the value 16 each:
00010000 000010000 00010000 00010000 00010000.... (x16)
This gives the correct crypt text
b3e46f11ba8d2b97c18769449a89e868
for the key in this example.
Related
I am trying to parse and validate DNSSEC responses without using any DNS specific libraries. I am able to get the hexstring representation of a RSA key from the public key field value present in the DNSKEY RRs. According to RFC 8017, the RSA public key is represented with the ASN.1 type RSAPublicKey format which has a modulus and exponent. However, it doesn't specify anything more.
The hexstring(same as in Wireshark) is
"03010001ac1f62b7f85d62c550211fd70ddbbca7326cde13dca235f26f76a5dd5872db601d775ecd189955ed96e749fd8e8e6af3e133e8a8eb8b8afc25730c6318f949de9436fde6ea280b5ccbc09a43ee357617905690fdc09cda06bc5ad3bcd1bc4e43de9a4769ff83453e96a74642b23daabae00398539cfca56b04c200776c4841724cb09674b519eb7e3506a3e08e4f96b5a733425a1c55eecb1613552c022b246b27141652d907cdbc6e30b5f3341a1ba5dfbb503edddbd01e85f1c4206642cfb312e14f2772fe8b66143ba847382e95fb86ba215342ae9cca803655bccadef1123e06f3cf1626840e11200b1acda118c50805c6eacfd271d930b93f2e332d9521"
I saw other similar posts and tried to follow the solutions. Most of the solutions try to get it from a pem file or binary data or base64 encoded form. When I try to convert the hex to those forms and use the solution, I get errors like 'RSA key format not supported' etc..
Is there anyway I can get the public key from the hex? I would really appreciate any inputs! Thanks!
I finally managed to find the solution.
According to RFC 3110 section 2, we can split the given value into exponent length, exponent and modulus. I split them as specified and converted the hexadecimal to integer. The text from RFC is below
The structure of the algorithm specific portion
of the RDATA part of such RRs is as shown below.
Field Size
----- ----
exponent length 1 or 3 octets (see text)
exponent as specified by length field
modulus remaining space
For interoperability, the exponent and modulus are each limited to
4096 bits in length. The public key exponent is a variable length
unsigned integer. Its length in octets is represented as one octet
if it is in the range of 1 to 255 and by a zero octet followed by a
two octet unsigned length if it is longer than 255 bytes. The public
key modulus field is a multiprecision unsigned integer. The length
of the modulus can be determined from the RDLENGTH and the preceding
RDATA fields including the exponent.
I am writing code for an SSH server and can not get past the Elliptic Curve Diffie-Hellman Key Exchange Reply part of the connection. The client also closes the connection and says "Host Key does not match the signature supplied".
I am using putty as the client and a PIC micro-controller is running the server code.
From RFC 5656 [SSH ECC Algorithm Integration] :
"The hash H is formed by applying the algorithm HASH on a
concatenation of the following:
string V_C, client's identification string (CR and LF excluded)
string V_S, server's identification string (CR and LF excluded)
string I_C, payload of the client's SSH_MSG_KEXINIT
string I_S, payload of the server's SSH_MSG_KEXINIT
string K_S, server's public host key
string Q_C, client's ephemeral public key octet string
string Q_S, server's ephemeral public key octet string
mpint K, shared secret
"
the host key algorithm and key exchange algorithm is ecdsa-sha2-nistp256 and ecdh-sha2-nistp256 respectively.
referring to RFC 4251 for data type representations, as well as the source code in openSHH (openBSD) this is what I have concatenated.
4 bytes for then length of V_C followed by V_C
4 bytes for then length of V_S followed by V_S
4 bytes for length of I_C followed by I_C (payload is from Message Code to the start of Random Padding)
4 bytes for length of I_S followed by I_S (payload is from Message Code to the start of Random Padding)
4 bytes for the length of K_S followed by K_S (for K_S I used the same group of bytes that is used to calculate the fingerprint)
4 bytes for the length of Q_C followed by Q_C (i used the uncompressed string which has length of 65 - 04||X-coordinate||Y-coordinate)
4 bytes for the length of Q_S followed by Q_S
4 bytes for the length of K followed by K (length is 32 or 33 depending is the leading bit is set or not. If it is set then K is preceded by a 00 byte)
Once concatenated I hash it with SHA256 because I'm using NISTP256. SHA256 outputs 32 bytes which is the size of the curve, so I take the whole SHA256 output and perform the signature algorithm on it.
I can never get the correct signature from my message concatenation.
I know my signature algorithm is correct because given the message hash output I can get the correct signature.
I know my shared secret is correct because I get the same output as online shared secret calculators.
I know the SHA256 is correct because I get the same result using online calculators.
This leads me to assume the error is in the concatenation of the exchange hash.
Any help is greatly appreciated, thanks.
ECDSA signature generation is non-deterministic, i.e. part of the input is the hash and part of the input consists of random bytes. So whatever you do, you will always get a different signature. This is all right because signature verification will still work.
The only way to get a repeated signature is to mess with the random number generator (during testing, you don't want to sign two values using the same random number: you'd expose the private key!).
I want to encrypt string with the same length of character string and decryption with same length of character string using sql server. For Example:
Encryption
Input: Encrypt("002581") -- with 6 characters
Result: a&pE12 -- output with same 6 characters in encrypted form
Decryption
Input: Decrypt("a&pE12") -- with 6 characters
Result: 002581 -- output with same 6 characters in decrypted form
Short answer: there is no such secure encryption scheme.
Longer answer: any kind of encryption scheme obfuscates content of a plain text to be indistinguishable from other messages from the same message space. To do so all cipher texts produced must be of the same length (ideally) regardless of an input plain text. At least the length should be different from a length of a plain text.
So please, don't even consider such an encryption technique. It's insecure by definition.
Anyone know how Base64 decoding Algorithm, as information in the internet many article, journal, and book explain how to encoding base64 algorithm But the decoding Base64 not explained.So my question is how to decode Base4 algorithm?
Thank you,
Hope Your Answer
Basically you take one character at the time and convert it to the bits that it represents. So if you find an A character it would translate into 000000 and the / character translates into 111111. Then you concatenate the bits. So you get 000000 | 111111. This however won't fit into a byte, you have to split up and shift the result to get 00000011 and 1111xxxx where xxxx is not known yet
Of course, you may only be able to do this using bytes in a high performance implementation, so you have two spurious bits for each character (separated by a space from the bits that actually mean something).
((00 000000 << 2) & 11111100) | ((00 111111 >> 4) & 00000011) -> 00000011
((00 111111 << 4) & 11110000) | ???????? -> 1111xxxx
...
First with the shift operator << you put the bits in place. Then with the binary AND operator & you single out those bits you want and then you use the binary OR | operator you assemble the bits of the two characters.
Now after 4 characters you will have 3 full bytes. It may however be that your result is not a multiple of three. In that case you have either two or three characters possibly followed by padding (=) at the end. One character is not possible as that would suggest an incomplete byte with only the highest bits set. In that case you should simply ignore the last spurious bits encoded by the last character.
Personally I like to use a state machine to do the decoding. I've already created a couple of base 64 streams that use a state machine in Java. It may be useful to only decode once you have 4 characters (3 full bytes) until you are at the end of the base 64 encoding.
has someone an idea, which hash-algorithn was used for these two hashes:
$S$DjzC6BKx24dNLU4UPyiCGXo6bJ3rDYbQdf/waPOwE9X36592NiFi
$S$DDLj98cyEH3azm0QvZq4E59PuczniTbfXiftWf5ED2qtcZYW5MTm
It looks a bit salted, but i can not determine if the Salt is $S$ or rather $S$D, because i know only these two. The length of these hashes without the substring $S$ would be 52.
If it was salted, it would not be as easy to spot the salt.
These are probably Base64 encoded. This means that 3 letters encode 2 bytes. Since we have 51 letters apart from the prefix $S$D, it is divisable by 3. That makes 34 Bytes or 136 bits.
136 bits are probably a hash function with 128 bits plus a CRC of 8 bits. Problem is: There are only one gazillion 128 hash funktions out there. But I'd go with md5, since it is so commonly used.