OBAKE Cryptanalysis:

Padding Oracle

In symmetric block cryptography - such as the OBAKE-512 algorithm - it is common to pad the bytes that make up an information block when the total amount of information block is less than the block size required by the algorithm - which usually occurs in the last bytes of the information. For example, in AES-128, 16 bytes per block are required, and if the information contains only 6, the algorithm will "pad" the remaining 10 bytes before submitting it to encryption.

The usual CBC mode of operation is vulnerable due to this approach, where the "Oracle" (usually a server) leaks data about whether the padding of an encrypted message is correct or not. This data can allow attackers to decrypt messages through the server, even without knowing the key used.

Since encryption standards are used on a massive scale (like AES, PKCS7, etc.), an attacker knows that the padding is done using the same byte value as the padded quantity - and this allows him to alter the encrypted block, creating by trial-and-error method blocks that the server will leak as authorized information. In the case of AES-128, for example, only 4080 attempts per block are required (255 shots x 16 bytes needed for the 128-bit algorithm), allowing an attacker to intercept and decrypt the information just by changing its "padded" structure.

The original POA attack was published in 2002 and has been used recently in various WEB structures, including languages (Java, ASP.NET, Ruby-on-Rails), databases (MySQL and Mongo), communication protocols (OpenSSL), and others.

Fortunately, because OBAKE-512 works with 512-bit blocks and uses a mode of operation similar to PCBC and CTR, adding also a type of HMAC as a "block authentication", this attack is unfeasible regarding information recovery (as recommended by John Black in its paper below). OBAKE also doesn't use standards like AES or PKCS7 for padding purposes and doesn't indicate how many bytes were filled at all.

With OBAKE, if a POA attack is conducted on the computer where it is running by changing any of the padded bytes of its block/memory stream, this will only cause the complete invalidation of the information being decoded, in a process known as the "avalanche effect".  In other words, the information is completely lost, but without breaking confidentiality, and the attacker won't get success in discovering it.

Bibliographic references

J. Black, H.Urtubia, "Side-Channel Attacks on Symmetric Encryption Schemes: The Case for Authenticated Encryption", University of Nevada, Reno, 2002.

K.G.Petterson, A.Yau, "Padding Oracle Attacks on the ISO CBC Mode Encryption Standard", Royal Holloway - University of London, 2004.

B. Canvel, A. Hiltgen, S. Vaudenay, and M. Vuagnoux. "Password Interception in a SSL/TLS Channel", CRYPTO 2003, LNCS Vol. 2729, 2003.

F. Valsorda, "Yet Another Padding Oracle in OpenSSL CBC Ciphersuites", https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphersuites/, 2016.

J. Black, S. Halevi, H. Krawczyk, T. Krovetz, and P. Rogaway, "UMAC: Fast and secure message authentication.", In Advances in Cryptology CRYPTO99, Computer Science, Springer-Verlag, 1999.

D. Bleichenbacher, "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS #1", In Advances in Cryptology CRYPTO98 vol 1462, Computer Science, SpringerVerlag, 1998.