Re: One-Time Pad Encryption Software to Debian Repository
Michael,
your understanding is correct and it’s XOR. Also the use of the password is more harmful than useless. If you glance in the source code, the author just generates MD from the password and XOR the input with it as a “protection”. This is more than useless this is actively harmful.
There’s more nonsense about combining two random numbers into one for “even more random”. (Oh gee, why we haven’t thought about this before...)
Anyway, after some more private conversation with the author, I think he’s beyond help. He’s so convinced that he’s right and standards based crypto has been flawed by NSA that he’s unable to listen. He’s also unable to understand that one must look at the security of the whole system and not just the security properties of the one-time pad function. Not to mention that he consistently calls functions that do XOR “encrypt” in the code.
I am sorry to say that it seems the Schneier’s law is in effect here... And I would normally ignore this, but perhaps some poor soul who Googles FinalCrypt will find this email and won’t put their sensitive data into the hands of this...
Ondřej
--
Ondřej Surý <ondrej@sury.org>
> On 15 Oct 2019, at 22:03, Michael Stone <mstone@debian.org> wrote:
>
> On Tue, Oct 15, 2019 at 05:07:33PM +0200, Ondřej Surý wrote:
>> First of all, all software in Debian must adhere to Debian Free Software
>> Guidelines. And I can’t find the source code anywhere on your website.
>>
>> That said - who you seem to use a lot of buzz words and bold claims, but I
>> would recommend the old wisdom: “don’t ever roll your own crypto”. I would
>> recommend you to speak to an actual cryptographer before you do more harm to
>> your users.
>>
>> I hope a cryptographic software based on hand-waving and no crypto audit would
>> never be uploaded in Debian.
>
> Source code seems to be at http://www.finalcrypt.org/downloads/other/finalcrypt_sourcecode.zip
> but otherwise I agree that using this versus a recognized encryption tools is a bad idea. The general mechanism seems to to generate a random string equal to the size of the input data, then perform some operation (presumably xor?) to generate ciphertext. The usual weak link from a theoretical standpoint is the strength of the pseudo random number generator. In this case it's using the java SecureRandom function, so it's as strong or weak as that. If you don't trust complicated mathematical functions to secure your data, I don't know why you'd trust SHA-256. The weak link from a practical standpoint is the need to securely store random pads equal in size to the data encrypted--if you can secure the one time pad, you could just as easily secure the data and not need the one time pad. Disclaimer: I only gave the source code a cursory glance so there may be additional elements of this implementation that I overlooked either for better or for worse.
Reply to: