Is it possible to determine the symmetric encryption method used by output size?Symmetric encryption mode where ciphertext size is plain text sizeUsing IV buffer after altered inside a Rijndael CBC Encryption/Decryption process as IV for next message?Exercise: Attack on a Two-Round DES CipherCommon password derivation function for different encryption methodsCracking an appliance's network protocolDetermine encryption method with input and outputSymmetric encryption vulnerable when encrypting and decrypting are the same?Is this an acceptable way to increase the block size of a block cipher?Crypto algorithm identification (reverse engineering)In BBC Sherlock's The Blind Banker, what type of cryptographic function is used by the Black Lotus?

Playing Doublets with the Primes

Is throwing dice a stochastic or a deterministic process?

What is the meaning of 「隣のおじいさんは言いました」

All of my Firefox add-ons been disabled suddenly, how can I re-enable them?

How to replace space with '+' symbol in a triangular array?

Explaining intravenous drug abuse to a small child

Reverse ColorFunction or ColorData

How long does it take a postcard to get from USA to Germany?

When do British people use the word "cookie"?

Efficient deletion of specific list entries

Collision domain question

When did England stop being a Papal fief?

Dimmer switch not connected to ground

Endgame puzzle: How to avoid stalemate and win?

What's the 2-minute timer on mobile Deutsche Bahn tickets?

Is there a reason why Turkey took the Balkan territories of the Ottoman Empire, instead of Greece or another of the Balkan states?

How did the Force make Luke hard to hit in the Battle of Yavin?

Can a player choose to add detail and flavor to their character's spells and abilities?

My large rocket is still flipping over

Why is the blank symbol not considered part of the input alphabet of a Turing machine?

Is there precedent or are there procedures for a US president refusing to concede to an electoral defeat?

As a GM, is it bad form to ask for a moment to think when improvising?

A 2-connected graph contains a path passing through all the odd degree vertices

How can I finally understand the confusing modal verb "мочь"?



Is it possible to determine the symmetric encryption method used by output size?


Symmetric encryption mode where ciphertext size is plain text sizeUsing IV buffer after altered inside a Rijndael CBC Encryption/Decryption process as IV for next message?Exercise: Attack on a Two-Round DES CipherCommon password derivation function for different encryption methodsCracking an appliance's network protocolDetermine encryption method with input and outputSymmetric encryption vulnerable when encrypting and decrypting are the same?Is this an acceptable way to increase the block size of a block cipher?Crypto algorithm identification (reverse engineering)In BBC Sherlock's The Blind Banker, what type of cryptographic function is used by the Black Lotus?













2












$begingroup$


I'm attempting to identify the method of encryption for a black-box symmetric encryptor that produces blocks of output that are 4 bytes in length (e.g. small inputs fit in 16 bytes, then 20 bytes and 24 bytes as more input characters are added).



It's symmetric encryption and the value is always the same for the same input text. Is it possible to determine which method of encryption is used? I'm assuming it's a block cipher as a result of the blocks of output it produces.










share|improve this question











$endgroup$







  • 1




    $begingroup$
    Related question on security.SE: security.stackexchange.com/questions/38797/… (I thought I remembered seeing a duplicate or at least a very similar question before on this site as well, but if so, I can't find it.)
    $endgroup$
    – Ilmari Karonen
    Apr 27 at 16:26
















2












$begingroup$


I'm attempting to identify the method of encryption for a black-box symmetric encryptor that produces blocks of output that are 4 bytes in length (e.g. small inputs fit in 16 bytes, then 20 bytes and 24 bytes as more input characters are added).



It's symmetric encryption and the value is always the same for the same input text. Is it possible to determine which method of encryption is used? I'm assuming it's a block cipher as a result of the blocks of output it produces.










share|improve this question











$endgroup$







  • 1




    $begingroup$
    Related question on security.SE: security.stackexchange.com/questions/38797/… (I thought I remembered seeing a duplicate or at least a very similar question before on this site as well, but if so, I can't find it.)
    $endgroup$
    – Ilmari Karonen
    Apr 27 at 16:26














2












2








2





$begingroup$


I'm attempting to identify the method of encryption for a black-box symmetric encryptor that produces blocks of output that are 4 bytes in length (e.g. small inputs fit in 16 bytes, then 20 bytes and 24 bytes as more input characters are added).



It's symmetric encryption and the value is always the same for the same input text. Is it possible to determine which method of encryption is used? I'm assuming it's a block cipher as a result of the blocks of output it produces.










share|improve this question











$endgroup$




I'm attempting to identify the method of encryption for a black-box symmetric encryptor that produces blocks of output that are 4 bytes in length (e.g. small inputs fit in 16 bytes, then 20 bytes and 24 bytes as more input characters are added).



It's symmetric encryption and the value is always the same for the same input text. Is it possible to determine which method of encryption is used? I'm assuming it's a block cipher as a result of the blocks of output it produces.







block-cipher symmetric blocksize






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 27 at 16:16







jSherz

















asked Apr 27 at 15:37









jSherzjSherz

1135




1135







  • 1




    $begingroup$
    Related question on security.SE: security.stackexchange.com/questions/38797/… (I thought I remembered seeing a duplicate or at least a very similar question before on this site as well, but if so, I can't find it.)
    $endgroup$
    – Ilmari Karonen
    Apr 27 at 16:26













  • 1




    $begingroup$
    Related question on security.SE: security.stackexchange.com/questions/38797/… (I thought I remembered seeing a duplicate or at least a very similar question before on this site as well, but if so, I can't find it.)
    $endgroup$
    – Ilmari Karonen
    Apr 27 at 16:26








1




1




$begingroup$
Related question on security.SE: security.stackexchange.com/questions/38797/… (I thought I remembered seeing a duplicate or at least a very similar question before on this site as well, but if so, I can't find it.)
$endgroup$
– Ilmari Karonen
Apr 27 at 16:26





$begingroup$
Related question on security.SE: security.stackexchange.com/questions/38797/… (I thought I remembered seeing a duplicate or at least a very similar question before on this site as well, but if so, I can't find it.)
$endgroup$
– Ilmari Karonen
Apr 27 at 16:26











2 Answers
2






active

oldest

votes


















2












$begingroup$

Simply put: No.



Without knowing other details, you cannot be sure. That being said, in the case you described, the black box uses 4 bytes blocks, which is rather uncommon with modern block ciphers. AES e.g. uses 128bits (16bytes), Blowfish uses 64bits (8bytes). 4byte block ciphers are very uncommon now. Even DES, which is quite outdated and old uses 8 bytes. The only block cipher used that has 32bit block size and comes to my mind is RC5.



So as you can see, you can make an educated guess. But given just the ciphertext, this does not inform you at all about encryption used. This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible.



You cannot even be sure that this is a block cipher. Could be a stream cipher with padding. So if the only thing you know is: "I have a box. I feed it data and it spits out data in chunks of 4 bytes" - then you know nothin', j Sherz






share|improve this answer











$endgroup$












  • $begingroup$
    Re: "This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible": I don't really agree with this. From a security standpoint, it would be perfectly fine for an encryption scheme to always produce output that begins with, say, This message encrypted with ...; see https://... for details. In practice, however, encryption schemes don't generally do this; instead, a secure protocol will typically provide a separate (metadata) field to indicate the encryption scheme in use.
    $endgroup$
    – ruakh
    Apr 27 at 20:15










  • $begingroup$
    @ruakh but This message encrypted with ...; see https://... for details is not the encrypted data, it's just a header. The actual encrypted data should still be indistinguishable from random data.
    $endgroup$
    – marcelm
    Apr 27 at 22:57










  • $begingroup$
    @marcelm: You can choose to make that distinction, but there's no need to; if the ciphertext requires a certain fixed prefix, then that prefix is essentially part of the ciphertext. If you'd like a different example: there's no problem with an encryption scheme where every Nth byte is a checksum, or one where the ciphertext only uses ASCII printable characters (for compatibility with MIME). There is literally no need for encrypted data to be "indistinguishable from random data". All that matters is that it be impossible to guess anything about the plaintext (other than its length).
    $endgroup$
    – ruakh
    Apr 27 at 23:36










  • $begingroup$
    I don't believe there's any block cipher which has a default block size that small. Even for RC5, 32 bits was the lowest it could go (default was 128, I think). But a few like SIMON and SPECK support 32-bit blocks. The cipher with the smallest default block size I know of is PRINTcipher, which has 48-bit blocks, IIRC.
    $endgroup$
    – forest
    Apr 28 at 8:44


















3












$begingroup$

You can try to determine the block size by modifying each byte of the input data, starting from the last one.



A typical block cipher implementation will mix the change into all other bytes in the block, and usually also to all following blocks, but not to blocks that come before it.



So if you observe e.g.:



 Plaintext Encrypted
0000 0000 2348 1234
0000 0001 2348 4292
0000 0010 2348 9823
0000 0100 2348 2149
0000 1000 2348 6785
0001 0000 8173 1437


you could be quite certain that it is a block cipher with 4-byte blocks.



For comparison, in typical applications of a stream cipher, only a single byte would usually change. If it is a stream cipher, you can obtain the keystream by encoding 000...0000, because it sounds like it doesn't have a random initialization vector.






share|improve this answer











$endgroup$












  • $begingroup$
    For block ciphers, that will depend entirely on the mode of operation.
    $endgroup$
    – Ilmari Karonen
    Apr 27 at 21:03











Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "281"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f70113%2fis-it-possible-to-determine-the-symmetric-encryption-method-used-by-output-size%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









2












$begingroup$

Simply put: No.



Without knowing other details, you cannot be sure. That being said, in the case you described, the black box uses 4 bytes blocks, which is rather uncommon with modern block ciphers. AES e.g. uses 128bits (16bytes), Blowfish uses 64bits (8bytes). 4byte block ciphers are very uncommon now. Even DES, which is quite outdated and old uses 8 bytes. The only block cipher used that has 32bit block size and comes to my mind is RC5.



So as you can see, you can make an educated guess. But given just the ciphertext, this does not inform you at all about encryption used. This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible.



You cannot even be sure that this is a block cipher. Could be a stream cipher with padding. So if the only thing you know is: "I have a box. I feed it data and it spits out data in chunks of 4 bytes" - then you know nothin', j Sherz






share|improve this answer











$endgroup$












  • $begingroup$
    Re: "This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible": I don't really agree with this. From a security standpoint, it would be perfectly fine for an encryption scheme to always produce output that begins with, say, This message encrypted with ...; see https://... for details. In practice, however, encryption schemes don't generally do this; instead, a secure protocol will typically provide a separate (metadata) field to indicate the encryption scheme in use.
    $endgroup$
    – ruakh
    Apr 27 at 20:15










  • $begingroup$
    @ruakh but This message encrypted with ...; see https://... for details is not the encrypted data, it's just a header. The actual encrypted data should still be indistinguishable from random data.
    $endgroup$
    – marcelm
    Apr 27 at 22:57










  • $begingroup$
    @marcelm: You can choose to make that distinction, but there's no need to; if the ciphertext requires a certain fixed prefix, then that prefix is essentially part of the ciphertext. If you'd like a different example: there's no problem with an encryption scheme where every Nth byte is a checksum, or one where the ciphertext only uses ASCII printable characters (for compatibility with MIME). There is literally no need for encrypted data to be "indistinguishable from random data". All that matters is that it be impossible to guess anything about the plaintext (other than its length).
    $endgroup$
    – ruakh
    Apr 27 at 23:36










  • $begingroup$
    I don't believe there's any block cipher which has a default block size that small. Even for RC5, 32 bits was the lowest it could go (default was 128, I think). But a few like SIMON and SPECK support 32-bit blocks. The cipher with the smallest default block size I know of is PRINTcipher, which has 48-bit blocks, IIRC.
    $endgroup$
    – forest
    Apr 28 at 8:44















2












$begingroup$

Simply put: No.



Without knowing other details, you cannot be sure. That being said, in the case you described, the black box uses 4 bytes blocks, which is rather uncommon with modern block ciphers. AES e.g. uses 128bits (16bytes), Blowfish uses 64bits (8bytes). 4byte block ciphers are very uncommon now. Even DES, which is quite outdated and old uses 8 bytes. The only block cipher used that has 32bit block size and comes to my mind is RC5.



So as you can see, you can make an educated guess. But given just the ciphertext, this does not inform you at all about encryption used. This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible.



You cannot even be sure that this is a block cipher. Could be a stream cipher with padding. So if the only thing you know is: "I have a box. I feed it data and it spits out data in chunks of 4 bytes" - then you know nothin', j Sherz






share|improve this answer











$endgroup$












  • $begingroup$
    Re: "This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible": I don't really agree with this. From a security standpoint, it would be perfectly fine for an encryption scheme to always produce output that begins with, say, This message encrypted with ...; see https://... for details. In practice, however, encryption schemes don't generally do this; instead, a secure protocol will typically provide a separate (metadata) field to indicate the encryption scheme in use.
    $endgroup$
    – ruakh
    Apr 27 at 20:15










  • $begingroup$
    @ruakh but This message encrypted with ...; see https://... for details is not the encrypted data, it's just a header. The actual encrypted data should still be indistinguishable from random data.
    $endgroup$
    – marcelm
    Apr 27 at 22:57










  • $begingroup$
    @marcelm: You can choose to make that distinction, but there's no need to; if the ciphertext requires a certain fixed prefix, then that prefix is essentially part of the ciphertext. If you'd like a different example: there's no problem with an encryption scheme where every Nth byte is a checksum, or one where the ciphertext only uses ASCII printable characters (for compatibility with MIME). There is literally no need for encrypted data to be "indistinguishable from random data". All that matters is that it be impossible to guess anything about the plaintext (other than its length).
    $endgroup$
    – ruakh
    Apr 27 at 23:36










  • $begingroup$
    I don't believe there's any block cipher which has a default block size that small. Even for RC5, 32 bits was the lowest it could go (default was 128, I think). But a few like SIMON and SPECK support 32-bit blocks. The cipher with the smallest default block size I know of is PRINTcipher, which has 48-bit blocks, IIRC.
    $endgroup$
    – forest
    Apr 28 at 8:44













2












2








2





$begingroup$

Simply put: No.



Without knowing other details, you cannot be sure. That being said, in the case you described, the black box uses 4 bytes blocks, which is rather uncommon with modern block ciphers. AES e.g. uses 128bits (16bytes), Blowfish uses 64bits (8bytes). 4byte block ciphers are very uncommon now. Even DES, which is quite outdated and old uses 8 bytes. The only block cipher used that has 32bit block size and comes to my mind is RC5.



So as you can see, you can make an educated guess. But given just the ciphertext, this does not inform you at all about encryption used. This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible.



You cannot even be sure that this is a block cipher. Could be a stream cipher with padding. So if the only thing you know is: "I have a box. I feed it data and it spits out data in chunks of 4 bytes" - then you know nothin', j Sherz






share|improve this answer











$endgroup$



Simply put: No.



Without knowing other details, you cannot be sure. That being said, in the case you described, the black box uses 4 bytes blocks, which is rather uncommon with modern block ciphers. AES e.g. uses 128bits (16bytes), Blowfish uses 64bits (8bytes). 4byte block ciphers are very uncommon now. Even DES, which is quite outdated and old uses 8 bytes. The only block cipher used that has 32bit block size and comes to my mind is RC5.



So as you can see, you can make an educated guess. But given just the ciphertext, this does not inform you at all about encryption used. This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible.



You cannot even be sure that this is a block cipher. Could be a stream cipher with padding. So if the only thing you know is: "I have a box. I feed it data and it spits out data in chunks of 4 bytes" - then you know nothin', j Sherz







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 27 at 16:41

























answered Apr 27 at 16:31









michnovkamichnovka

22139




22139











  • $begingroup$
    Re: "This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible": I don't really agree with this. From a security standpoint, it would be perfectly fine for an encryption scheme to always produce output that begins with, say, This message encrypted with ...; see https://... for details. In practice, however, encryption schemes don't generally do this; instead, a secure protocol will typically provide a separate (metadata) field to indicate the encryption scheme in use.
    $endgroup$
    – ruakh
    Apr 27 at 20:15










  • $begingroup$
    @ruakh but This message encrypted with ...; see https://... for details is not the encrypted data, it's just a header. The actual encrypted data should still be indistinguishable from random data.
    $endgroup$
    – marcelm
    Apr 27 at 22:57










  • $begingroup$
    @marcelm: You can choose to make that distinction, but there's no need to; if the ciphertext requires a certain fixed prefix, then that prefix is essentially part of the ciphertext. If you'd like a different example: there's no problem with an encryption scheme where every Nth byte is a checksum, or one where the ciphertext only uses ASCII printable characters (for compatibility with MIME). There is literally no need for encrypted data to be "indistinguishable from random data". All that matters is that it be impossible to guess anything about the plaintext (other than its length).
    $endgroup$
    – ruakh
    Apr 27 at 23:36










  • $begingroup$
    I don't believe there's any block cipher which has a default block size that small. Even for RC5, 32 bits was the lowest it could go (default was 128, I think). But a few like SIMON and SPECK support 32-bit blocks. The cipher with the smallest default block size I know of is PRINTcipher, which has 48-bit blocks, IIRC.
    $endgroup$
    – forest
    Apr 28 at 8:44
















  • $begingroup$
    Re: "This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible": I don't really agree with this. From a security standpoint, it would be perfectly fine for an encryption scheme to always produce output that begins with, say, This message encrypted with ...; see https://... for details. In practice, however, encryption schemes don't generally do this; instead, a secure protocol will typically provide a separate (metadata) field to indicate the encryption scheme in use.
    $endgroup$
    – ruakh
    Apr 27 at 20:15










  • $begingroup$
    @ruakh but This message encrypted with ...; see https://... for details is not the encrypted data, it's just a header. The actual encrypted data should still be indistinguishable from random data.
    $endgroup$
    – marcelm
    Apr 27 at 22:57










  • $begingroup$
    @marcelm: You can choose to make that distinction, but there's no need to; if the ciphertext requires a certain fixed prefix, then that prefix is essentially part of the ciphertext. If you'd like a different example: there's no problem with an encryption scheme where every Nth byte is a checksum, or one where the ciphertext only uses ASCII printable characters (for compatibility with MIME). There is literally no need for encrypted data to be "indistinguishable from random data". All that matters is that it be impossible to guess anything about the plaintext (other than its length).
    $endgroup$
    – ruakh
    Apr 27 at 23:36










  • $begingroup$
    I don't believe there's any block cipher which has a default block size that small. Even for RC5, 32 bits was the lowest it could go (default was 128, I think). But a few like SIMON and SPECK support 32-bit blocks. The cipher with the smallest default block size I know of is PRINTcipher, which has 48-bit blocks, IIRC.
    $endgroup$
    – forest
    Apr 28 at 8:44















$begingroup$
Re: "This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible": I don't really agree with this. From a security standpoint, it would be perfectly fine for an encryption scheme to always produce output that begins with, say, This message encrypted with ...; see https://... for details. In practice, however, encryption schemes don't generally do this; instead, a secure protocol will typically provide a separate (metadata) field to indicate the encryption scheme in use.
$endgroup$
– ruakh
Apr 27 at 20:15




$begingroup$
Re: "This is one of the key aspects of cryptography btw, encrypted data should look as much as random data as possible": I don't really agree with this. From a security standpoint, it would be perfectly fine for an encryption scheme to always produce output that begins with, say, This message encrypted with ...; see https://... for details. In practice, however, encryption schemes don't generally do this; instead, a secure protocol will typically provide a separate (metadata) field to indicate the encryption scheme in use.
$endgroup$
– ruakh
Apr 27 at 20:15












$begingroup$
@ruakh but This message encrypted with ...; see https://... for details is not the encrypted data, it's just a header. The actual encrypted data should still be indistinguishable from random data.
$endgroup$
– marcelm
Apr 27 at 22:57




$begingroup$
@ruakh but This message encrypted with ...; see https://... for details is not the encrypted data, it's just a header. The actual encrypted data should still be indistinguishable from random data.
$endgroup$
– marcelm
Apr 27 at 22:57












$begingroup$
@marcelm: You can choose to make that distinction, but there's no need to; if the ciphertext requires a certain fixed prefix, then that prefix is essentially part of the ciphertext. If you'd like a different example: there's no problem with an encryption scheme where every Nth byte is a checksum, or one where the ciphertext only uses ASCII printable characters (for compatibility with MIME). There is literally no need for encrypted data to be "indistinguishable from random data". All that matters is that it be impossible to guess anything about the plaintext (other than its length).
$endgroup$
– ruakh
Apr 27 at 23:36




$begingroup$
@marcelm: You can choose to make that distinction, but there's no need to; if the ciphertext requires a certain fixed prefix, then that prefix is essentially part of the ciphertext. If you'd like a different example: there's no problem with an encryption scheme where every Nth byte is a checksum, or one where the ciphertext only uses ASCII printable characters (for compatibility with MIME). There is literally no need for encrypted data to be "indistinguishable from random data". All that matters is that it be impossible to guess anything about the plaintext (other than its length).
$endgroup$
– ruakh
Apr 27 at 23:36












$begingroup$
I don't believe there's any block cipher which has a default block size that small. Even for RC5, 32 bits was the lowest it could go (default was 128, I think). But a few like SIMON and SPECK support 32-bit blocks. The cipher with the smallest default block size I know of is PRINTcipher, which has 48-bit blocks, IIRC.
$endgroup$
– forest
Apr 28 at 8:44




$begingroup$
I don't believe there's any block cipher which has a default block size that small. Even for RC5, 32 bits was the lowest it could go (default was 128, I think). But a few like SIMON and SPECK support 32-bit blocks. The cipher with the smallest default block size I know of is PRINTcipher, which has 48-bit blocks, IIRC.
$endgroup$
– forest
Apr 28 at 8:44











3












$begingroup$

You can try to determine the block size by modifying each byte of the input data, starting from the last one.



A typical block cipher implementation will mix the change into all other bytes in the block, and usually also to all following blocks, but not to blocks that come before it.



So if you observe e.g.:



 Plaintext Encrypted
0000 0000 2348 1234
0000 0001 2348 4292
0000 0010 2348 9823
0000 0100 2348 2149
0000 1000 2348 6785
0001 0000 8173 1437


you could be quite certain that it is a block cipher with 4-byte blocks.



For comparison, in typical applications of a stream cipher, only a single byte would usually change. If it is a stream cipher, you can obtain the keystream by encoding 000...0000, because it sounds like it doesn't have a random initialization vector.






share|improve this answer











$endgroup$












  • $begingroup$
    For block ciphers, that will depend entirely on the mode of operation.
    $endgroup$
    – Ilmari Karonen
    Apr 27 at 21:03















3












$begingroup$

You can try to determine the block size by modifying each byte of the input data, starting from the last one.



A typical block cipher implementation will mix the change into all other bytes in the block, and usually also to all following blocks, but not to blocks that come before it.



So if you observe e.g.:



 Plaintext Encrypted
0000 0000 2348 1234
0000 0001 2348 4292
0000 0010 2348 9823
0000 0100 2348 2149
0000 1000 2348 6785
0001 0000 8173 1437


you could be quite certain that it is a block cipher with 4-byte blocks.



For comparison, in typical applications of a stream cipher, only a single byte would usually change. If it is a stream cipher, you can obtain the keystream by encoding 000...0000, because it sounds like it doesn't have a random initialization vector.






share|improve this answer











$endgroup$












  • $begingroup$
    For block ciphers, that will depend entirely on the mode of operation.
    $endgroup$
    – Ilmari Karonen
    Apr 27 at 21:03













3












3








3





$begingroup$

You can try to determine the block size by modifying each byte of the input data, starting from the last one.



A typical block cipher implementation will mix the change into all other bytes in the block, and usually also to all following blocks, but not to blocks that come before it.



So if you observe e.g.:



 Plaintext Encrypted
0000 0000 2348 1234
0000 0001 2348 4292
0000 0010 2348 9823
0000 0100 2348 2149
0000 1000 2348 6785
0001 0000 8173 1437


you could be quite certain that it is a block cipher with 4-byte blocks.



For comparison, in typical applications of a stream cipher, only a single byte would usually change. If it is a stream cipher, you can obtain the keystream by encoding 000...0000, because it sounds like it doesn't have a random initialization vector.






share|improve this answer











$endgroup$



You can try to determine the block size by modifying each byte of the input data, starting from the last one.



A typical block cipher implementation will mix the change into all other bytes in the block, and usually also to all following blocks, but not to blocks that come before it.



So if you observe e.g.:



 Plaintext Encrypted
0000 0000 2348 1234
0000 0001 2348 4292
0000 0010 2348 9823
0000 0100 2348 2149
0000 1000 2348 6785
0001 0000 8173 1437


you could be quite certain that it is a block cipher with 4-byte blocks.



For comparison, in typical applications of a stream cipher, only a single byte would usually change. If it is a stream cipher, you can obtain the keystream by encoding 000...0000, because it sounds like it doesn't have a random initialization vector.







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 28 at 6:50

























answered Apr 27 at 20:13









jpajpa

1914




1914











  • $begingroup$
    For block ciphers, that will depend entirely on the mode of operation.
    $endgroup$
    – Ilmari Karonen
    Apr 27 at 21:03
















  • $begingroup$
    For block ciphers, that will depend entirely on the mode of operation.
    $endgroup$
    – Ilmari Karonen
    Apr 27 at 21:03















$begingroup$
For block ciphers, that will depend entirely on the mode of operation.
$endgroup$
– Ilmari Karonen
Apr 27 at 21:03




$begingroup$
For block ciphers, that will depend entirely on the mode of operation.
$endgroup$
– Ilmari Karonen
Apr 27 at 21:03

















draft saved

draft discarded
















































Thanks for contributing an answer to Cryptography Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f70113%2fis-it-possible-to-determine-the-symmetric-encryption-method-used-by-output-size%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020