I'm looking into disabling certain ciphers and I'm trying to wrap my head around how the block ciphers are named in Windows. Specifically what the numbers follow the name mean. For example, RC4 40/128, DES 56/56, AES 128/128 or AES 256/256. I thought maybe this was key size/block size but that doesn't make sense. Take AES 256/256. It is my understanding that for it to be AES it needs a block size of 128. Thus the last number can't specify block size. Or take the RC4 ciphers. It would appear that the first number is the key size but it's a stream cipher, so what is the 128? OR DES 56/56. I thought DES had a key size of 56 bits and a block size of 64 bits? Does anyone know the history or the reasoning behind the naming?
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.
Is it at all possible in OpenSSL to change the block size? I am using Ruby and from what I can tell there is no way to do this.
I just want to confirm this is true. Here is a link to the only method I can find related to block size which just returns what the block size is. https://ruby-doc.org/stdlib-2.4.0/libdoc/openssl/rdoc/OpenSSL/Cipher.html#method-i-block_size but other than that I don't see a way to do this. Is it possible? I know I can set the key size but not the block size. It seems it is stuck with a 128-bit block size?
Specifically I want to use AES which I understand is only a 128-bit block size. But Rijndael which is what AES is based on can be set up to a 256-bit block size so I was wondering if OpenSSL would allow me to set the block size.
No, it's not possible.
AES, as standardized by NIST, is a subset of the Rijndael cipher family. While Rijndael supports several different block and key sizes, AES is only defined to use a block size of 128 bits and a key size of either 128, 192 or 256 bits.
The list of ciphers supported by OpenSSL only includes AES, not Rijndael.
The OpenSSL AES implementation is hardcoded to use a block size of 16 bytes (= 128 bits).
Short of adding Rijndael as a new cipher to OpenSSL and rebuilding the library yourself, you will not be able to use OpenSSL to encrypt or decrypt data using any of the Rijndael variants other than those standardized as AES.
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.
Is there a well-known (to be considered) algorithm that can encrypt/decrypt any arbitrary byte inside the file based on the password entered and the offset inside the file.
(Databyte, Offset, Password) => EncryptedByte
(EncryptedByte, Offset, Password) => DataByte
And is there some fundamental weakness in this approach or it's still theoretically possible to build it strong enough
Update:
More datails: Any cryptographic algorithm has input and output. For many existing ones the input operates on large blocks. I want to operate on only one byte, but the system based on this can only can remap bytes and weak by default, but if we take the position in the file of this byte, we for example can take the bits of this position value to interpret them as some operation on some step (0: xor, 1: shitf) and create the encrypted byte with this. But it's too simple, I'm looking for something stronger.
Maybe it's not very efficient but how about this:
for encryption use:
encryptedDataByte = Encrypt(offset,key) ^ dataByte
for decryption use:
dataByte = Encrypt(offset,key) ^ encryptedDataByte
Where Encrypt(offset,key) might be e.g. 3DES or AES (with padding the offset, if needed, and throwing away all but one result bytes)
If you can live with block sizes of 16 byte, you can try the XTS-mode described in the wikipedia article about Disk encryption theory (the advantage being that some good cryptologists already looked at it).
If you really need byte-wise encryption, I doubt that there is an established solution. In the conference Crypto 2009 there was a talk about How to Encipher Messages on a Small Domain: Deterministic Encryption and the Thorp Shuffle. In your case the domain is a byte, and as this is a power of 2, a Thorp Shuffle corresponds to a maximally unbalanced Feistel network. Maybe one can build something using the position and the password as key, but I'd be surprised if a home-made solution will be secure.
You can use AES in Counter Mode where you divide your input into blocks of 16 bytes (128 bits) and then basically encrypt a counter on the block number to get a pseudo-random 16 bytes that you can XOR with the plaintext. It is critically important to not use the same counter start value (and/or initialization vector) for the same key ever again or you will open yourself for an easy attack where an attacker can use a simple xor to recover the key.
You mention that you want to only operate on individual bytes, but this approach would give you that flexibility. Output Feedback Mode is another common one, but you have to be careful in its use.
You might consider using the EAX mode for better security. Also, make sure you're using something like PBKDF-2 or scrypt to generate your encryption key from the password.
However, as with most cryptography related issues, it's much better to use a rigorously tested and evaluated library rather than rolling your own.
Basically what you need to do is generate some value X (probably 1 byte) based on the offset and password, and use this to encrypt/decrypt the byte at that offset. We'll call it
X = f(offset,password)
The problem is that an attacker that "knows something" about the file contents (e.g. the file is English text, or a JPEG) can come up with an estimate (or sometimes be certain) of what an X could be. So he has a "rough idea" about many X values, and for each of these he knows what the offset is. There is a lot of information available.
Now, it would be nice if all that information were of little use to the attacker. For most purposes, using a cryptographic hash function (like SHA-1) will give you a reasonable assurance of decent security.
But I must stress that if this is something critical, consult an expert.
One possibility is a One Time Pad, possibly using the password to seed some pseudo-random number generator. One time pads theoretically achieve perfect secrecy, but there are some caveats. It should do what you're looking for though.
I need to create a database column which will store a string encrypted using Triple DES. How do I determine the length of the encrypted string column?
(Answers for algorithms other than Triple DES are also welcome.)
Block-ciphers such as DES, 3DES and AES can only operate on blocks of bytes. DES and 3DES operate on block of 8 bytes and AES on blocks of 16 bytes.
To handle this, you usually apply a reversible padding to your plaintext before encrypting it. It will mostly always be "PKCS"-padding (also called PKCS5- or PKCS7-padding).
PKCS-padding adds at least one byte such that the padded text has a length divisible with the block-length (8 bytes for 3DES). The value of the padding-bytes is the number of bytes added. Fx. ABCDEF is padded to ABCDEF0505050505 and 0011223344556677 is padded to 0011223344566770808080808080808. Note that this is easy to remove: you just look at the final byte of the padded bytes, verify that it is between 1 and the block-length, and remove that number of bytes from the end (verifying that each removed byte has the correct value).
Finally, to answer your question: Assuming you are using 3DES with CBC encryption and PKCS-padding - which you probably are - the encryption of a string of length n will have length:
n + 8 - (n % 8)
Using Triple DES does not change the string's length but it will be rounded to the next 64 bit boundary. If you intend to "display" it, you'll have to encoded it (like in Base64 though.
As for other algorithms, it is difficult ot answer as there are plenty. Block ciphers will always pad input to match their block size whereas many stream ciphers will not.
Triple DES uses three 56-bit DES keys, giving 168 bit keys. It's block size is 64-bit.