# Is this block encryption scheme using PCBC for RSA secure?

I stumbled over this post, containing code to encrypt larger messages with RSA by splitting them into blocks using PCBC mode I will copy the relevant part here, but for details see the original posting or this archived copy.

# As indicated in Prologue, this is an implementation of an idea of the present
# author to closely combine asymmetric and symmetric encryptions, which
# presumably is novel.
#
# Encryption will be done with receiver's public key on blocks chained in a way
# analogous to the chaining in common symmetric block encryption processing. The
# chaining value is initialized by a pseudo-random iv. A plaintext block (as a
# big integer resulting from character to integer transformation) is xor-ed with
# the chaining value before being encrypted. The chaining value is then updated
# by xor-ing it with the current plaintext block and the ciphertext block. (In
# distinction to the well-known CBC chaining, we empoly thus PCBC chaining. Note
# that the variable chaining sums up via xoring the values of pp and cc of all
# preceding blocks such that it has a in this context very desirable high error
# propagation property. The iv and the last chaining value obtained are then
# encrypted and appended to ct, the list of the ciphertext blocks, for purposes
# of authentication (integrity check). It is to be particularly remarked that we
# have, as described, integrated certain well-known techniqes commonly employed
# in symmetric block encryption into asymmetric encryption. A normal message is
# processed in this example. In its place there could of course be anything else
# instead, e.g. a secret key for use in a symmetric block cipher (which is how
# RSA is commonly used in other software).
#
# Users employ for encryption and decryption the functions
# rsaencryptplaintexttoct() and rsadecryptcttoplaintext() respectively in case
# the given secret material is in form of a text string, and the functions
# rsaencryptbytearraytoct() and rsadecryptcttobytearray() respectively in case
# the given secret material is in form of a byte sequence.

# Encrypt pt, a list of integers of mb bits (integers in [0, 2**mb-1]) to ct,
# another list of integers, with the public key of the receiver. Note that ct
# returned is a list of integers which may be larger than mb bits, i.e. up to
# receivern-1.
#
# mb: See comments of rsakeygeneration().
#
# (receivere, receivern): The public key of the receiver.

def encrypttoct(pt,mb,receivere,receivern):
assert mb%8 ==0 and mb >= 2048 and 2**mb < receivern
tpmb=2**mb
tpmbn1=tpmb-1
RANDOM=random.SystemRandom()
# A pseudo-random iv is generated to be the initial chaining value.
iv=RANDOM.randint(1,tpmb-1)
chaining=iv
ct=[]
# Each pp is a block of plaintext.
for pp in pt:
assert pp < tpmb
u=chaining^pp
# Encrypt with receiver's public key to obtain the ciphertext block.
cc=pow(u,receivere,receivern)
ct.append(cc)
# Update the chaining value by xor-ing it with the plaintext block and the
# ciphertext block (limited to mb bits).
chaining^=pp^(cc&tpmbn1)
# Here at the end of the loop the chaining has its last value.
# Encrypt iv and the last chaining value and put them into ct.
g=pow(iv,receivere,receivern)
h=pow(chaining,receivere,receivern)
ct+=[g,h]
return(ct)


(all rights to this code belong to the original author Mok-Kong Shen

It strangely looks like this is somehow the PCBC mode decryption as described in Wikipedia used for encryption.

Is there any issue resulting from using that with RSA instead of a symmetric cipher?

Assuming that RSA is as secure as BlockCipher XYZ, will this give the same security as PCBC used with XYZ?

• This doesn't look anything like PCBC mode. PCBC mode would be utterly insecure. I'm not sure about this scheme. – Maarten Bodewes Aug 3 '16 at 10:09
• Oh, I made the mistake of looking at the wrong diagram. It seems this is a bit like the decryption of PCBC used for the encryption. – Josef says Reinstate Monica Aug 3 '16 at 10:25
• The main difference is the propagation of the chaining value. That's pretty smart and definitely required as RSA requires random padding, not just unpredictable padding, because anybody can encrypt, so you need some kind of "secret" value. – Maarten Bodewes Aug 3 '16 at 10:28
• I have had a long discussion about the claim by @MaartenBodewes that my scheme is to be considered broken via chosen plaintext attacks. Please take a look at the related discussions here and here. In the unlikely case the related chat-rooms here at Crypto.SE don’t suit you, an alternative way would be that you participate in the group from which you copied my stuff. – Mok-Kong Shen Aug 5 '16 at 20:51

## 1 Answer

Is there any issue resulting from using that with RSA instead of a symmetric cipher?

The difference - with regards to security - between symmetric and asymmetric encryption is that anybody is supposed to have the public key for asymmetric encryption, including the attacker. This has to be taken into account when generating a mode of operation for RSA.

Assuming that RSA is as secure as BlockCipher XYZ, will this give the same security as PCBC used with XYZ?

Nope. Assume that the first plaintext block is zero. Then the IV (initial chaining value) is encrypted twice in this scheme. As modular exponentiation itself is deterministic, this will result in repetition within the ciphertext. This repetition will show that the plaintext block is zero, thus leaking information to an attacker.

That's a fundamental break in CPA security. There may be other issues, but this is enough to declare the scheme to be broken when used as direct replacement of CBC or PCBC with a symmetric cipher.

• Comments are not for extended discussion; this conversation has been moved to chat. – e-sushi Aug 5 '16 at 16:24