rsa encryption with stonybrook modula

thanx for the super explanations. it gave some more insides of what is
happening in this (for me) whole blackbox.
i am glad that you found that problem too. i have a 40 byte (byte
array) encrypted with rc4 that then is encrypted using the rsa and the
decryption was failing sporadically.
drove me nuts (not that i am not nuts already). i'll try the padding
and i hope i'll get that to work.
can't wait to get a solution - thank you for the insides and your
analysis.
should you have any more pointers, i'll be glad to read them

richard

Norman Black schrieb:

> "Norman Black" <nospam@nospam.com> wrote in message
> news:NwgGe.8272$wA1.7848@trnddc09...
> > "Norman Black" <nospam@nospam.com> wrote in message
> > news:U4gGe.8269$wA1.942@trnddc09...
> >>I have been able to duplicate the problem in all cases. The problem is in
> >>the conversion from raw byte data to/from a VLI number. The problem occurs
> >>with leading zero byes in the raw data. I will look into what the best
> >>solution is.
> >
> > I can elaborate on this further. Say you want to encrypt 4 bytes of data
> > and that data is 0000FFFFh. That is a numerical 65535. RSA does not
> > encrypt bytes of data like symmetric encryption algorithms like DES. RSA
> > encrypts numbers. Encrypt(public) 65535 in RSA and that results in a
> > number. Then decrypt(private) the number and you get back 65535. How many
> > bytes should be stored for the 65535. 2 bytes, 4 bytes, 5 bytes? RSA does
> > not know nor does it care. It operates on numbers not bytes of data. 65535
> > takes two bytyes minimum but can be stored in a number of bytes more than
> > that. FFFFh = 0000000000000000FFFFh. When you decrypt an encrypted RSA
> > item you have to know what the size of the resulting item needs to be so
> > you can add leading pad zeros if necessary. Or just never encrypt any data
> > bytes with leading zeros. Say you are encrypting 40 bytes of data. Fudge
> > it to 41 with a leading 1 byte. When you decrypt you can ignore the extra
> > byte you added.
> >
>
> To elaborate on my elaboration. This issue is one good reason why you use an
> encoding algorithm like OAEP when using RSA encryption. The encoding
> algorithm always results in a known encrpytion data size regardless of the
> input message length. Since you know the size data in then you know what the
> data output size should be.
>
> Of course another reason for the encoding algorithms is additional security.
> OAEP encodes using a random number. The decode does not need to know
> anything about the encoding randomness. Cool how people come up with
> algorithms like that.
>
> Norman

"rko" <rko@compugroup.com> wrote in message
news:1122618646.090601.230980@z14g2000cwz.googlegr oups.com...
> thanx for the super explanations. it gave some more insides of what is
> happening in this (for me) whole blackbox.
> i am glad that you found that problem too. i have a 40 byte (byte
> array) encrypted with rc4 that then is encrypted using the rsa and the
> decryption was failing sporadically.
> drove me nuts (not that i am not nuts already). i'll try the padding
> and i hope i'll get that to work.
> can't wait to get a solution - thank you for the insides and your
> analysis.
> should you have any more pointers, i'll be glad to read them

There is no "solution" for using the raw RSA.PublicFunction and
RSA.PrivateFunction as you have show in your example code. The solution is
to know that when you decrypt that the item size is known and insert any
necessary leading zeros. As I said, RSA cannot know what the destination
decrypted data size should be. Another way to deal with this would be to
encode the item size into the encrypted data itself. For example if you have
40 bytes then append one byte with the value of 40. Encrypt that (41 bytes).
When you decrypt take the last byte and if the buffer bytes are not the
correct size (41) then insert leading zeros as necessary given the buffer
data and the size fields. A mechanism like this allows for arbitrary packet
sizes.

The only "solution" is a fix to the OAEP encryption procedures in the RSA
module. Also the PSS signing procedures. They have a known packet size and
the decrypt needs to account for this and add leading zeros as necessary.
The raw RSA routines cannot know what is necessary.

Norman

Here are fixes for the RSA module OAEP decrypt and PSS verify procedures.
They handle the leading zeros issue.

PROCEDURE Decrypt_OAEP_SHA1(crypt : RSA;
cipher : ADDRESS;
cipherLen : CARDINAL;
encodingParams : ADDRESS;
encodingParamsLen : CARDINAL;
message : ADDRESS;
VAR INOUT messageLen : CARDINAL) : BOOLEAN;
VAR
emLen : CARDINAL;
pad : CARDINAL;
i : CARDINAL;
BEGIN
IF crypt^.sha1 = NIL THEN
crypt^.sha1 := SHA1.Create();
END;

emLen := crypt^.bufSize;
IF PrivateFunction(crypt,
cipher, cipherLen,
crypt^.buffer, emLen)
THEN
pad := crypt^.emLen-emLen;
IF pad <> 0 THEN
MoveMem(ADR(crypt^.buffer^[pad]), crypt^.buffer, emLen);
i := 0;
REPEAT
DEC(pad);
crypt^.buffer^[i] := 0;
INC(i);
UNTIL pad = 0;
END;
RETURN Decode_OAEP(crypt^.buffer, crypt^.emLen,
encodingParams, encodingParamsLen,
message, messageLen,
HashFunc_SHA1, crypt^.sha1, SHA1.HashLength);
END;
RETURN FALSE;
END Decrypt_OAEP_SHA1;

PROCEDURE Verify_PSS_SHA1(crypt : RSA;
cipher : ADDRESS;
cipherLen : CARDINAL;
saltLen : CARDINAL;
messageHash : ADDRESS) : BOOLEAN;
VAR
emLen : CARDINAL;
pad : CARDINAL;
i : CARDINAL;
BEGIN
IF crypt^.sha1 = NIL THEN
crypt^.sha1 := SHA1.Create();
END;

IF PublicFunction(crypt,
cipher, cipherLen,
crypt^.buffer, emLen)
THEN
pad := crypt^.emLen-emLen;
IF pad <> 0 THEN
MoveMem(ADR(crypt^.buffer^[pad]), crypt^.buffer, emLen);
i := 0;
REPEAT
DEC(pad);
crypt^.buffer^[i] := 0;
INC(i);
UNTIL pad = 0;
END;
RETURN Verify_PSS(crypt^.buffer, crypt^.emLen,
saltLen,
messageHash,
HashFunc_SHA1, crypt^.sha1, SHA1.HashLength);
END;

RETURN FALSE;
END Verify_PSS_SHA1;


Norman

thank you very, very much all the kind help.

richard


Norman Black schrieb:

> Here are fixes for the RSA module OAEP decrypt and PSS verify procedures.
> They handle the leading zeros issue.
>
> PROCEDURE Decrypt_OAEP_SHA1(crypt : RSA;
> cipher : ADDRESS;
> cipherLen : CARDINAL;
> encodingParams : ADDRESS;
> encodingParamsLen : CARDINAL;
> message : ADDRESS;
> VAR INOUT messageLen : CARDINAL) : BOOLEAN;
> VAR
> emLen : CARDINAL;
> pad : CARDINAL;
> i : CARDINAL;
> BEGIN
> IF crypt^.sha1 = NIL THEN
> crypt^.sha1 := SHA1.Create();
> END;
>
> emLen := crypt^.bufSize;
> IF PrivateFunction(crypt,
> cipher, cipherLen,
> crypt^.buffer, emLen)
> THEN
> pad := crypt^.emLen-emLen;
> IF pad <> 0 THEN
> MoveMem(ADR(crypt^.buffer^[pad]), crypt^.buffer, emLen);
> i := 0;
> REPEAT
> DEC(pad);
> crypt^.buffer^[i] := 0;
> INC(i);
> UNTIL pad = 0;
> END;
> RETURN Decode_OAEP(crypt^.buffer, crypt^.emLen,
> encodingParams, encodingParamsLen,
> message, messageLen,
> HashFunc_SHA1, crypt^.sha1, SHA1.HashLength);
> END;
> RETURN FALSE;
> END Decrypt_OAEP_SHA1;
>
> PROCEDURE Verify_PSS_SHA1(crypt : RSA;
> cipher : ADDRESS;
> cipherLen : CARDINAL;
> saltLen : CARDINAL;
> messageHash : ADDRESS) : BOOLEAN;
> VAR
> emLen : CARDINAL;
> pad : CARDINAL;
> i : CARDINAL;
> BEGIN
> IF crypt^.sha1 = NIL THEN
> crypt^.sha1 := SHA1.Create();
> END;
>
> IF PublicFunction(crypt,
> cipher, cipherLen,
> crypt^.buffer, emLen)
> THEN
> pad := crypt^.emLen-emLen;
> IF pad <> 0 THEN
> MoveMem(ADR(crypt^.buffer^[pad]), crypt^.buffer, emLen);
> i := 0;
> REPEAT
> DEC(pad);
> crypt^.buffer^[i] := 0;
> INC(i);
> UNTIL pad = 0;
> END;
> RETURN Verify_PSS(crypt^.buffer, crypt^.emLen,
> saltLen,
> messageHash,
> HashFunc_SHA1, crypt^.sha1, SHA1.HashLength);
> END;
>
> RETURN FALSE;
> END Verify_PSS_SHA1;
>
>
> Norman