You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reading through the code comments, it looks like you are including some information in the cipher text, which IMHO should not be there.
c.f. " FFHHTTRRRR******-------------------------------------DDDD******* "
I think it should rather be like this:
FF******-------------------------------------DDDD*******
Both, sender and receiver, are in possession of the pad. Determining the length of fuzz from pad data is easily possible for both parties without the need of transmitting that info, unless you don't want random fuzz lengths
The text was updated successfully, but these errors were encountered:
Thanks! I think you're right -- I was careless in writing that comment. The information is not actually included in the ciphertext; it's just read from the pad at encryption and decryption time. I will update the comment to be clearer on the difference between what gets used versus what gets included in the ciphertext.
Thank you for noticing this.
Yes, I do consider F to be sensitive information. If you know F, then you know the version of OneTime that was used to encrypt the file, which means you have a lower bound -- and a probable upper bound -- on the date that the message was encrypted. This would be an unacceptable information leak about the sender's relationship to the plaintext.
Ok, I see your point re F. It's not an issue for me, but I understand it is for some.
Thanks for updating the comments to reflect that H,R,T are not included in the message.
If they were, they'd needlessly increase message size and disclose raw pad data.
Reading through the code comments, it looks like you are including some information in the cipher text, which IMHO should not be there.
c.f. " FFHHTTRRRR******-------------------------------------DDDD******* "
I think it should rather be like this:
FF******-------------------------------------DDDD*******
Both, sender and receiver, are in possession of the pad. Determining the length of fuzz from pad data is easily possible for both parties without the need of transmitting that info, unless you don't want random fuzz lengths
The text was updated successfully, but these errors were encountered: