tROAesEncryptionEnvelope performance and security improvements

Remoting SDK
1

Hello Remobjects team,

whilst browsing the sourcecode of TROAesEncryptionEnvelope, I couldn’t help but noticing that the method “Encodepassword” (a hash calculator) is called upon every incoming/outgoing data packet. This wastes CPU time for no reason, because the hash only changes if the passphrase changes… The longer the passphrase (which is generally a good idea), the more performance is lost… IMHO it would be better to calculate the hash just once when the passphrase is set and to discard the passphrase itself at runtime.

Another disadvantage of the current method is that the passphrase is stored as cleartext both in RAM and in the DFM, which is dead easy to hack. I can work around the DFM vulnerability by setting the passphrase at runtime but the component still stores it unencrypted in RAM.

2

You can do as I have done and implement your own envelope using what ever cipher and technique that favours you.
TROAesEncryptionEnvelope is not the holy grain but gives enough clues to do your own implementation.

3

This suggestion by @bobokonijn of moving the calculation of Encodepassword to TROAESEncryptionEnvelope.SetPassword and storing the value and then removing it from being done on every message makes complete sense. Can we add this to the ticket list to be done?

//changes

TROAESEncryptionEnvelope = class(TROMessageEnvelope)
private
FBinaryKey: TBytes; //new

procedure TROAESEncryptionEnvelope.SetPassword(const Value: string);
begin
fPassword := Value;
FBinaryKey := EncodePassword(fPassword); //new
end;

remove from procedure TROAESEncryptionEnvelope.intProcessIncoming(Source,
Dest: TStream; aMessage: IROMessage); and procedure TROAESEncryptionEnvelope.intProcessOutgoing(Source,
Dest: TStream; aMessage: IROMessage);

FBinaryKey: TBytes;
FBinaryKey := EncodePassword(fPassword);

4

Thanks, logged as bugs://79702

5

bugs://79702 got closed with status fixed.