I encrypt a UTF-8 string + current timestamp using AES 128bit CTR mode with a 4 bytes random initialization vector, which is generated by NodeJS's crypto.randomBytes().
Finally I base64 encode the whole output, using a URL-friendly base64 variant.
Question: the AES output should be unique due to timestamp + random data. But is final base64 string also guaranteed to be unique?
Thanks in advance!
Yes, Base64 is a reversible transformation, so if input is unique than output will be also unique.
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 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.
I need to print an encrypted string as is in a rdlc report. My problem is if the string contain a plus sign it creates a new line in the Textbox. How to avoid this?
Encryption produces output that is binary and contains many bytes that have no displayable representation.
Because of this if encrypted data needs to be displayed it is generally either Base64 (best for computers) or hexadecimal (best for people) encoded.
It seems that you may have base64 encoded encrypted data and that is generally composed of the upper and lowercase characters, the 10 digits, "+", "/" and "=". You can not delete these and expect to recover the encrypted data.
If these characters present a problem they can be many times be escaped in some manor or another encoding can be chosen such as hexadecimal or an alternate Base64 character set, see Base64. If you choose an alternate Base64 character set interoperability will most likely be impaired.
Note: More information would produce a better answer.
I had to replace the "+" with "รท".
Users don't notice is it since the PDF is just a visual representation of the CFDI, I haven't had any issues with it.
What is the output format of the SHA256? It is composed by letters and numbers only? And it is case insensitive?
As with most (all?) crypto hashes, the output of SHA-256 is binary data. How that binary data is encoded in a text format is up to you. For example, you could encode it as hex, or base64.
If I have a string that will be encoded with Base64, Md5, or some other hash or encryption function, is there a way to at least be able to make a fair guess as to what it is?
You can try to guess but with a lot of false results. Md5 always have 32 characters, base64 have a limited set of possible characters, etc.