Duplicati, EFAIL, exFAT, Speck, Truths

Duplicati 2 backup, blocks and compaction. Some people said that restore works fine. It's totally different if you backup files so that you've got complete file / backup set. With databases the usual situation is that the file itself is broken into many or even all of the backup sets. Due to de-duplication. Which means that you can't restore the file (completely), if any of the backup sets got any gaps or issues. I've also been thinking about backing up data to multiple destinations. But usually it's good to use also separate backup technologies for different destinations for reliability reasons. If you only use Duplicati all of your backups could be totally ruined. Yet in situations where I need to have files on multiple locations, I'll usually run backup to local storage drive, and then mirror the data set to destinations using whatever tool works best with that destination. rsync, robocopy, ssh, webdav, sync (with whatever destination having it's own sync app). - This works very well. But it's always important to have that alternate backup, unless duplicati won't work. Also having local backup set (Duplicati or not) is very important for restore speed. The remote backups are only for total loss of site, cases. If something needs to be restored, using (more or less) local source, like NAS is much better and faster option.
About EFAIL - Duh! So much disinformation was circulating about this. It's clearly complex MUA failure, and technically got nothing at all to do with especially the PGP / OpenPGP / GnuPG encryption. Of course the message modification was possible, due to lack of authenticated encryption in some cases. Like when using really old software. Because the - MDC - https://en.wikipedia.org/wiki/Cryptographic_hash_function - is mandatory in GnuPG, even in case you don't sign the message. But even if message modification would be possible, this kind of fail shouldn't. Guess how many times I've said that you shouldn't use insanely complex code to deal with anything requiring security. That's exactly why the computer handling plaintext, can't ever be connected to internet, nor run browser, email client or something "stupidly complex" and insecure code. I've described several times in my blog how to do these things securely. And that's exactly the reason why LC4 and LS47 "on paper or off computer" encryption were created. To avoid the insecure component with "practically unlimited" and huge attack surface, aka your computer / phone, which is absolutely insecure and there's no known way to fix it. As long as it's connected to Internet. Link to LC4 and LS47 tiles. So was something like this "efail" huge security risk totally expected? Yes, it was. Some things are more or less infinitely broken, like computer security. - Bruce Schneier said: "Programmers are human and vulnerabilities are inevitable". Yep, seconded.
Microsoft exFAT encryption AArrGGh! Once again, all files which should be accessed are encrypted with key which I don't have. Or I have, but using it would require way too much work, probably hours, or more. So, thanks. At least I know the data is safe. Microsoft .PFILE'd me... ( .pfile extension )
Speck and Simon ciphers rejected as ISO encryption standard for Internet of Things (IoT) devices. It seems that experts are (rightfully?) worried that those NSA designed ciphers could contain some trickery. As we know, this wouldn't be anything new. Speck seems wonderfully simple and straightforward compared to many complex algorithms. Simon seems also quite simple, with fixed constants.
Standard system configuration truths:
Hanlon's razor - "Never attribute to malice that which is adequately explained by stupidity".
Clarke's third law - , bit mangled: "Any sufficiently advanced incompetence is indistinguishable from malice".
Nice post about: HTTP headers. Yes, just as usual. If you take a good look at something, you'll find out that most of people and businesses are doing it wrong. Nothing new there. Resources & focus are limited, no way to get everything perfect. It just works has to be good enough quite often.

2019-10-20