It should be as simple as changing the 1st item in the schema:

1 Byte Recepient count: 1-255 recepients allowed

To 4 bytes and take it to an unsigned int32 (as of course you cannot have a negative amount of recipients). Then use the BitConverter to retrieve the int (rather than just taking the byte directly).

So in short, no, it’s not an algorithm limitation or bad practice. Use whatever value your project requires (if you have to go to an Uint64 I’d really like to know what you’re working on though! ).

I was hoping to be able to use this as a base for a larger encryption project, potentially requiring more than 255 recipients for any given message. From looking at the code it looks like a simple change in the number of bytes read/written (when adding recipient count to the MemoryStream) would make more recipients possible, but I don’t know enough about cryptography to know if 255 is an algorithm limitation, bad practice/not recommended, etc.

Can you explain a little more as to why you chose this value and whether or not more recipients would be possible/recommended?

Thanks again!

(the only difference is I extend ClientBase as I need to set the ClientCertificate – it seems the only way round this is to still have a config file!)

Error:
System.InvalidOperationException was unhandled
Message=Could not find default endpoint element that references contract ‘VPSTransferLibrary.VPSWcfTransport.IReceiveService’ in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.