I have some inputs and outputs of a encryption function and i'm trying to find algorithm of it:
input:hello
output:eee5ab79be1ca8033fc790603b4d308c3c0a4e38
input:test
output:ebf3c7fb5cecf8ca04ca79dd0bbaa6e42120ffec
input:tennis
output:97e6335558d16337a5e712a3525a3766ab7a3454
input:a
output:0c57bfdc2835cdf0fab05fe08d37ffc5373f1ba8
input:b
output:67482459148ba04c2f12e83cdd18cbfe343978ee
input:c
output:380050d0dbf8293d16b7b4837d84abf4ae6b6d83
input:d
output:d0eae9775bac581b174dc4eaf0f6cc6cd284ad61
input:e
output:00626906c39804e9f441800c629900fd706002f8
input:f
output:7d6ae6cf3aa98f05bace0abc355474810f37c83d
input:0
output:324df299bcf4760d1523cb63ef5c4b2d1d4d371b
input:1
output:4a35df90d96cf1ed7aa008e99d1637b941d29605
input:2
output:2629ecf6a43d69aa06f7dfd5eabdba318d23132d
input:3
output:90225564ae81006f3747fb90d51dab4bac26fbac
input:4
output:3100cc28c4ef0f79e2d29c77a265aef1b2d0e70a
input:5
output:325fbdc73b2e874c287471e315949dc972846434
input:6
output:7d1bad0d82c2b62cfa0719f45acc50732579c206
input:7
output:89dd853798aea657f9ce236b248993b1f5c7bf55
input:8
output:83038f49e7954004aeafd2073b0c0c5a91d1ae7a
input:9
output:ab8fcf8532ed3c0367d6e5fa7230e4317296d6e4
outputs are hexadecimal and fixed length(40 characters)
inputs are unicode characters
Can anyone help me?
What you're asking isn't possible, because we would need to guess both the encryption algorithm and the encryption key
In addition, it appears that the algorithm in question has a 160-bit block size (which is why the output is a fixed 160 bits - presumably if it were given 161 bits of input then its output would be 320 bits), but I am not aware of any encryption algorithm with a 160-bit block size - block sizes are typically a power of 2 (e.g. 128 bits or 256 bits). Maybe it's an encryption algorithm with a 128 bit block size plus a 32 bit checksum, but that's just complicating an already impossible task.
Related
The reason why I ask this question is that we all know that this algorithm will fill the plaintext data into a multiple of 32 bytes,
so how will the key with less than 32 bytes or more be handled?
Because aes256 encryption algorithm is used in many websites or programs,
and usually we don't set a 32 byte password.
In that case, how should the algorithm go on?
Or is there any place where I can perfectly read the algorithms of all modes of aes256?
I am willing to check the source code of the algorithm by myself.
(this is not an advertisement)
but before that, I wrote an encryption algorithm myself.
I named it "sn_aes2048", Its function is:
"if the plaintext data is not a multiple of 256 bytes,
it will be filled with a multiple of 256 bytes, and the key is the same operation.
16 rounds of encryption will be performed by default,
and the data of the key will be updated in each round of encryption.
You may not believe that this algorithm is both symmetric encryption and asymmetric encryption.
Yes, yes, it is an encryption algorithm similar to aes256."
The reason why I ask this question is that we all know that this algorithm will fill the plaintext data into a multiple of 32 bytes,
AES is a block cipher, which must be used with a mode of operation to be used as a general cipher. Some mode of operations (ECB, CBC) require padding (or ciphertext stealing) to be able to operate. So AES - the block cipher algorithm - doesn't do that, and many more modes of operation (CTR, GCM) don't require padding at all.
so how will the key with less than 32 bytes or more be handled?
AES - the block cipher - supports key sizes of 128, 192 and 256 bits, and that's it. It doesn't perform any actions on the key itself.
and usually we don't set a 32 byte password.
Yes but a password is not a key. Both are secrets, but there are different requirements for keys and passwords. You can indeed use a password based key derivation function (PBKDF) as has been commented below. Other methods exist as well such as PAKE schemes.
You may not believe that this algorithm is both symmetric encryption and asymmetric encryption.
I don't believe it can be any good if you don't even understand the concepts of a symmetric key and a password - or the concept of padding which you're trying to re-invent, but feel free to publish a paper.
Or is there any place where I can perfectly read the algorithms of all modes of aes256?
Try "block cipher mode of operation" and "Padding" on Wikipedia for a start. Then buy a book or follow a course on Cryptography. It is an academic field - creating your own algorithm from scratch is like screwing together your own automobile.
I am trying to figure out if using 32 bit CRC will produce collision on 32 byte array.
BackGround
My system reads some configuration whenever it boots up from an external flash. I store the SHA256 hash of the last know configuration and when ever I read the configuration I calculate the SHA256 hash and compare it. If the two hash are different then the data is different.
I need to take that SHA256 and make it into a 32bit hash for another part of the system (due to some legacy code restrictions).
Questions
Will there be a high number of collision if I compute the 32 bit CRC on the 32 byte hash from SHA256?
I calculate the probability of collision to be 0. Can you let me know if this is correct?
The number of sample K is always 2 in my problem (I think) because I am calculating 32 bit CRC on two 32 bytes byte array (SHA256 byte array).
see calculation here
That's correct, if by "0" you mean that very small number. That small number is the probability that you would get a 32-bit CRC from random data that accidentally matches what you were expecting. It is simply 2-32.
I understand that there is a 256 and 512 versions because they are all powers of 2. But where 384 came from?
I know that binary representation of 384 is 110000000 but I can't understand the logic.
It is not in the middle between 256 and 512. It is not even a logarithmic middle.
Why 384?
A quick look on Wikipedia finds this:
SHA-256 and SHA-512 are novel hash functions computed with 32-bit and
64-bit words, respectively. They use different shift amounts and
additive constants, but their structures are otherwise virtually
identical, differing only in the number of rounds. SHA-224 and SHA-384
are simply truncated versions of the first two, computed with
different initial values.
Looking at the comparison between all the variants, it seems that SHA-384 is more resistant to length extension attacks than SHA-512 (its longer version).
You can find a more detailed answer on Cryptography Stack Exchange: here.
256 + 128 = 384
It is nothing but addition of two values which are above mentioned powers of 2 !!
tl;dr
I recently started listening to a security podcast, and heard the following sentence (paraphrasing)
One of the good hallmarks of a cryptographically strong random number is its lack of compressibility
Which immediately got me thinking, can random data be lossless-ly compressed? I started reading, and found this wikipedia article. A quoted block is below
In particular, files of random data cannot be consistently compressed by any conceivable lossless data compression algorithm: indeed, this result is used to define the concept of randomness in algorithmic complexity theory.
I understand the pigeon hole principle, so I'm assuming I'm way wrong here somewhere, but what am I missing?
IDEA:
Assume you have an asymmetric variable-length encryption method by which you could convert any N bit into either a N-16 bit number or N+16 bit number. Is this possible?
IF we had an assymetric algorithm could either make the data say 16 bits bigger or 16 bits smaller, then I think I can come up with an algorithm for reliably producing lossless compression.
Lossless Compression Algorithm for Arbitrary Data
Break the initial data into chunks of a given size. Then use a "key" and attempt to compress each chunk as follows.
function compress(data)
compressedData = []
chunks = data.splitBy(chunkSize);
foreach chunk in chunks
encryptedChunk = encrypt(chunk, key)
if (encryptedChunk.Length <= chunk.Length - 16) // arbitrary amount
compressedData.append(0) // 1 bit, not an integer
compressedData.append(encryptedChunk)
else
compressedData.append(1) // 1 bit, not an integer
compressedData.append(chunk)
end foreach
return compressedData;
end function
And for de-compression, if you know the chunk-size, then each chunk that begins with 0 perform the asymmetric encryption and append the data to the on going array. If the chunk begins with a 0 simply append the data as-is. If the encryption method produces the 16-bit smaller value even 1/16 as often as the 16-bit larger value, then this will work right? Each chunk is either 1 bit bigger, or 15 bits smaller.
One other consideration is that the "key" used by the compression algorithm can be either fixed or perhaps appended to the beginning of the compressed data. Same consideration for the chunk size.
There are 2N−16 possible (N−16)-bit sequences, and 2N possible N-bit sequences. Consequently, no more than one in every 216 N-bit sequence can be losslessly compressed to N−16 bits. So it will happen a lot less frequently than 1/16 of the time. It will happen at most 1/65536 of the time.
As your reasoning indicates, the remaining N-bit sequences could be expanded to N+1 bits; there is no need to waste an additional 15 bits encoding them. All the same, the probability of a random N-bit sequence being in the set of (N−16)-bit compressible sequences is so small that the average compression (or expected compression) will continue to be 1.0 (at best).
I have 99,999 bit flags that I need to represent uniquely with 32 bits or less. Any of the bits can be set and I need to know if the set bits differ from a comparable set of bits. I am considering using CRC to store a unique value hash but I am not sure if collisions will be a problem. Ideally, less than 500 of these bits will be set at any given time, but they will not be know ahead of time.
Is there suitable hash or other algorithm to uniquely represent these bits?
NO!
Without some other information about those bit flags to identify that certain combinations are impossible, this cannot be done. If all combinations are possible, then you will need to use 99,999 bits to store your 99,999 bit flags.
Edit:
Based on the background information that this is to reduce network usage and the expectation is that only about 500 of the bits are set, there are techniques that can be used, but none are a simple hash, and none are efficient enough to store in 32 bits. I would start by looking at Arithmetic Coding. This uses a probability distribution of the characters that you want to send (0.5% 1, 99.5% 0) to compress data. By my computations, you can "expect" a compression of about 22 times. But, for signals that are considered rare, you will pay the price by needing to transmit a signal larger than your starting 99,999 bits.