I have a bank device that is used to do money transfers among accounts. I'm curious about trying to figure out what algorithm is used to cipher the input. It follows the next conditions
-The text that needs to be cipher consists of only 8 digits (e.g. 00000000, 00000001, 99999999, etc)
-It uses some key/password to cipher this input
-The key/pass is a string of n characters
-The output should be of the same length (8 digits)
Is there any standard crypto algos for this?
Yes, this is so-called Format-preserving encryption. And yes, it's standartized.
https://doi.org/10.6028%2FNIST.SP.800-38G
https://en.wikipedia.org/wiki/Format-preserving_encryption
Related
There's a program that encrypts any values. The problem is, I can't understand what the algorithm is.
So, e.g.
input is 1, output is cwjtCNNxuYsB+fns/5h66g==
input is 2, output is UR/EJ8GNC/eG5zFXBwbXDw== and so on.
When the input becomes bigger, the output becomes bigger as well:
input London is the capital of Great Britain, output mnmxU29GVF+e+zn6Y8k246TdbF3wafzl7/ohdgA9KEvZNoLG02JW5HdcwZJNiZmA.
The strange things here are these "+", "/" and "=".
I can't understand how to classify such cipher.
That output (with the "+", "/" and "=") is base64 encoding.
Base64 is an encoding standard that uses a number of ASCII characters to represent binary data, by translating it into a radix-64 representation.
It's widely used to make messages that are encrypted easy to transport over email, WhatsApp, iMessage, etc.
Looking at your examples, they also seem to be encrypted, however, all ciphers will produce larger and larger ciphertext as plaintext input increases.
I expect this is some type of symmetric block cipher.
AES - the Advanced Encryption Standard, has a block size of 128-bits. Ergo, no matter how small the input (even 1 bit) it will be padded to at least 128-bits. Given that your inputs of '1' and '-2' are in fact encrypted to a 128-bit output, I expect this is likely AES.
Indeed "London is the capital of Great Britain" is also a multiple of 128-bits, at 384-bit's of ciphertext.
mnmxU29GVF+e+zn6Y8k246TdbF3wafzl7/ohdgA9KEvZNoLG02JW5HdcwZJNiZmA
->
100110100111100110110001010100110110111101000110010101000101111110011110111110110011100111111010011000111100100100110110111000111010010011011101011011000101110111110000011010011111110011100101111011111111101000100001011101100000000000111101001010000100101111011001001101101000001011000110110100110110001001010110111001000111011101011100110000011001001001001101100010011001100110000000 == 384-bits/128-bit block size = 3 Blocks of data.
I have an API to call where I have to encrypt my data using RSA/ECB/PKCS1 Padding & AES/CBC/PKCS5PADDING.
Sample Data: {"KEY":"VALUE"}
Step.1:
I have to generate a random number of 16 digit. eg: '1234567890123456'
Step.2:
Do RSA/ECB/PKCS1Padding to random number and base64Encode the result. we get "encrypted_key"
Step.3:
Concatenate random number & data:
DATA = 1234567890123456{"KEY":"VALUE"}
Step.4:
Do AES/CBC/PKCS5Padding on DATA (from Step 3) using random number(1234567890123456) as KEY & Base64Encoded random number as IV. we get "ENCRYPTED_DATA"
So, for Step 1 I am using JSEncrypt javascript library.
for Step 4 I am using CrytoJS.AES.encrypt() function. I am pretty sure that my JSEncrypt function is running fine as the client is able to decrypt it but client is not able to decrypt my data. I feel that I am making a mistake while using CryptoJS.
Can someone guide me properly on how to use the library.
What I am doing is:
KEY = '1234567890123456'
IV = MTIzNDU2Nzg5MDEyMzQ1Ng== (result of btoa('1234567890123456') )
DATA = "1234567890123456{"KEY":"VAL"}"
cryptedData = Crypto.AES.encrypt(DATA, KEY, {iv: IV, mode: CryptoJS.mode.CBC,padding:CryptoJS.pad.Pkcs7})
I am told to use PKCS5Padding in AES/CBC Encryption ( Step 4 ) but it seems that AES does not support PKCS5Padding but PKCS7Padding.
I think I am making a mistake in the way I am passing KEY & IV to CryptoJS.
Any help will be greatly appreciated.
For the start lets see why are you doing the exercise. RSA is intended to encode only limited amout of data. So we use "hybrid encryption", where the data are encrypted using a symmetric cipher with a random key and the key itself is encrypted using RSA
Encryption works on binary data, to safely transmit binary data, the data are encoded to printable form (hex or base64)
Step.1: I have to generate a random number of 16 digit
What we see is 16 digits 0-9. That's not really safe. Generating 16 digits you will get a key of 10^16, which is equals of approx 2^53 (if I did the math wrong, please comment).
You need to generate 16 random bytes (digits 0-256 resulting in 2^128 key). That is your DEK (data encryption key).
You may encode the DEK to be in printable form, in hexadecimal encoding it will have 32 characters.
Step.2:
ok, you now get encrypted encoded_encryption_key
Step 3, Step 4
And here you should understand what are you doing.
encrypt DATA using DEK ( not encoded random number in binary form), you will get encrypted_data. You can encode the result to encoded_encrypted_data
concatenate the encrypted key and encrypted data. It. is up to you to choose if you encode it before or after encoding. I suggest you make concatenation of encoded_encryption_key and encoded_encrypted_data with some separator, because if RSA key length changes, the length of encoded_encryption_key changes too
Make sure to discuss with the client what format is expected exactly.
Notes:
IV needs to be 16 bytes long for AES and for CryptoJS I believe it needs to be Hex encoded, so using btoa may not be the best idea. I believe the CryptoJS just trims the value to 16 bytes, but formally it is not correct.
CBC cipher needs some sort of integrity check, I suggest to add some HMAC or signature to the result (otherwise someone could change the ciphertext without you being able to detect the tamper)
but it seems that AES does not support PKCS5Padding but PKCS7Padding.
Indeed AES supports Pkcs7. Pkcs5 is functionally the same, but defined on 64 blocks. The designation is still used in Java as heritage from DES encryption.
I'm working on a homework assignment on paper where I must design an RSA cryptosystem and show the steps of encrypting/decrypting a message by hand.
I have selected and calculated my p, q, n, and phi(n). I am now encrypting the message "HELLO". I have started by breaking each letter into its ASCII equivalent such that H = 72, E = 69, and so forth.
My question is should I encrypt/decrypt each letter separately to/from ciphertext or is there a better way to do it while leaving it as one string?
It seems daunting to have to do the Extended Euclidean Algorithm by hand for all the letters in order to find the decryption key.
I ask this question because I assume that RSA handles this in a better way as to not have to run encryption on each character but encrypt it as a whole.
TL;DR Should I encrypt each letter separately or can I do it all at once?
RSA encrypts the whole message by converting the whole text into a very large integer usually by putting an integer representation of each character in the text side by side and then applying the public key. If each character is encrypted separately, the encrypted message will be vulnerable to frequency analysis.
I am working on encryption & decryption of data using AES-CCM.
While studying AES, I came across a word called S-Box.
What is S-Box, and the relationship with AES? How can it be calculated? Is it depends on symmetric key or not?
How will cypher text be generated in AES-CCM 128 bit?
The S-Boxes are a system that is used in symmetric cryptographic algorithms to substitute and obscure the relationship between the key and the text that you want to cypher.
You can see more in this article. Here, you have a part:
There are different types of cyphers according to their design [68]. One of these is the ​Substitution–PermutationNetwork (SPN) that generates the ciphered text by applying substitution and permutation rounds to the original text and the symmetric key to create confusion. To do this, it must be used the Substitution boxes (S-boxes) and Permutation boxes (P-boxes). The S-boxes substitute one-to-one the bits of a block of the input text in the round with bits of the output text. This output is taken as an input in the P-boxes and then it permutes all the bits that will be used as S-box input in the next round.
As #CGG said, S-boxes are a component of a Substitution-Permutation Network. The Wikipedia entry has good diagrams which will help explain how they work.
Think of an S-box as a simple substitution cipher -- A=1, B=2, etc. In an SPN, you run input through an S-box to substitute new values, then you run that result through a P-box (permutation) to distribute the modified bits out to as many S-boxes as possible. This loop repeats to spread the changes throughout the entire cipher text.
In general, an S-box replaces the input bits with an identical number of output bits. This exchange should be 1:1 to provide invertibility (i.e. you must be able to reverse the operation in order to decrypt), should employ the avalanche effect (so changing 1 bit of input changes about half the output bits), and should depend on every bit of input.
I was wondering:
1) if I compute the digest of some datas with SHA-512 => resulting in a hash of 64 bytes
2) and then I sign this hash with RSA-1024 => so a block of 128 bytes, which is bigger than the 64 bytes of the digest
=> does it mean in the end my signed hash will be exactly 128 bytes?
Thanks a lot for any info.
With RSA, as specified by PKCS#1, the data to be signed is first hashed with a hash function, then the result is padded (a more or less complex operation which transforms the hash result into a modular integer), and then the mathematical operation of RSA is applied on that number. The result is a n-bit integer, where n is the length in bits of the "modulus", usually called "the RSA key size". Basically, for RSA-1024, n is 1024. A 1024-bit integer is encoded as 128 bytes, exactly, as per the encoding method described in PKCS#1 (PKCS#1 is very readable and not too long).
Whether a n-bit RSA key can be used to sign data with a hash function which produces outputs of length m depends on the details of the padding. As the name suggests, padding involves adding some extra data around the hash output, hence n must be greater than m, leaving some room for the extra data. A 1024-bit key can be used with SHA-512 (which produces 512-bit strings). You could not use a 640-bit key with SHA-512 (and you would not, anyway, since 640-bit RSA keys can be broken -- albeit not trivially).