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

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.

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

• 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. – ruakh Apr 27 '19 at 20:15
• @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. – marcelm Apr 27 '19 at 22:57
• @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). – ruakh Apr 27 '19 at 23:36
• 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. – forest Apr 28 '19 at 8:44
• The CFB or OFB modes can also be configured for 4 byte feedback per block cipher operation (and any block cipher). – Maarten Bodewes May 12 '19 at 2:55

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.