lucgommans

It certifies what it says on the tin: an independent audit was performed by Cure53. You are correct in believing that certifying complex software to be free of bugs to be practically impossible at the moment.

But which product would you rather use: one where you have to trust the developers, or one where you have to trust the developers plus an independent team got 5 weeks of paid time to study it for any flaws?

As someone working in this industry, I can also say it's significantly harder to find exploitable bugs after another audit team went over it already. A criminal would have the same problem and might chose another target instead.

> Too often, they're also product marketing documents, beginning and concluding with "overall assessments" of the target software that is almost invariably positive

We have some customers that clearly come to us to get reports they can share with investors, and not that many come back so either they weren't happy or (I like to think) they've checked that box and aren't doing further tests. But never did one of them ask us to rephrase something for overt marketing reasons or provide even a single sentence of marketing material to include. Perhaps we were clear that this is not something we do and that's why they don't come back, though since they also don't ask and still order a test, that doesn't seem logical.

I also can't say that I've seen a Cure53 report where this is the case, including this one. If anything, the statement about a critical vulnerability in the previous pentest could make one weary, so I applaud Mozilla for publishing this rather than silent fixing and keeping it under wraps.

> Vendors pay for public-facing reports, as an extra line item in the [statement of work]

This is the first I hear of that, though the public scrutiny does mean we spend quite a bit of extra review time on such reports (from spell checking to going over every substantial statement and rating) so I could understand if Cure53 has different practices from ours. That does not mean they were bought (assuming, for the sake of argument, that a premium was paid, which I don't think there was).

> that norm should be that public-facing reports can be provided only in the same dry, technical form they're presented to development teams in ordinary, non-public projects

That is exactly what we do, and I am quite sure Cure53 works the same way in this regard. We review more deeply if we know ahead of time it's going to be public, as I wrote above, to make sure things are correct (especially since English is none of our native languages), but we don't alter the contents.

> I think third-party assessment reports like these are a real problem in our industry.

I really don't understand where this comment is coming from unless you have very different experiences with customers or public reports where you are based. At a minimum it doesn't apply to the report at hand. Too often these things are kept secret and it's a rare opportunity that we don't have to swear silence on our work. I'd love to do that more.

Via Austin Z. Henley's favorite Wikipedia articles about science: https://web.eecs.utk.edu/~azh/blog/favwikiarticles.html

> add a UI that shows the user the key and helps them verify it [...] probably nowhere near as good as Threema

Indeed, Threema really has to get more credit for this one.

How many people verify their contacts in Signal when they opportunistically get the chance? Wire? WhatsApp? Matrix?

My mother in law wanted to verify keys with me in Threema of her own volition. In Signal, which she tried for the same reason (securely communicating medical data between colleagues), she didn't even know it was possible, let alone that she should be doing that.

Good point, should have thought of that. I have a bunch of things open where I don't want to reload the page so restarting in safe mode is a bit tricky now, but unless someone happens to know the exact answer I can try this on the weekend and perhaps narrow it down, thanks :)

Which OS is that on? Mine was on Linux, perhaps that makes a difference. Also I have a rather crappy cpu (i5-8250U); for you I still see the gaps even if they're smaller (both in absolute terms but if I'm seeing it correctly also in proportion to network loading time), so perhaps a faster cpu helps as well.

Speaking of Firefox performance, does anyone know what introduces pauses in page loading? A page of 900 bytes HTML, with 2 KB of CSS and a 33 KB background image, takes 918 ms to load. Only a third of that is network stuff (DNS resolving, TLS setup, etc.; adding up the 'duration' values). Screenshot of page with loading graph: https://i.snipboard.io/AcqWb4.jpg Notice the huge gap between HTML loaded and starting to load CSS, for example, where it does not appear to be doing or waiting for anything.

Seeing the title and initially glancing at the drawing where it says "reading XUL.dll" I thought they addressed this, as I noticed this problem a while ago and I figured it was something about this multi-process browser experience having to load everything anew or constantly do inter-process communication, but the post is actually about various other performance issues. Does anyone know what's up with this one?

Just to be clear, I'm not saying Firefox is slower than browser X or anything. I just happen to notice this in Firefox because I'm a Firefox user.

I wonder where they measure from, as it claims >1 second of loading time for what is ~500ms in my browser.

And my browser is also absurdly slow, now that I look at it. The HTML at https://lucgommans.nl is 978 bytes, the CSS 2KB, and the ping 39ms. With DNS+TCP+TLS+HTTP, the HTML downloads in 159ms. And then it waits. And waits. Then, after 134ms, it decides that DOM content has been loaded and fires the DOMContentLoaded event (there is no JS on the page). And then it waits some more, until after waiting 177ms it decides to start downloading the CSS which finishes in 44ms. And then it waits again for 40ms, downloads the 33KB background image in 80ms, and finally clocks the total loading time at 508ms.

How fast should it be? The loading times are 283ms altogether (sequentially), how long does parsing 3KB of data take on a modern CPU? Close to zero right?

I remember in iirc ~2007-2015, quite regularly there would be news that browser X had optimized the DOM parser, or rewritten the JavaScript engine, or cut off some time with this or that. What even is going on here, did all this go out the window with the multi-process browser where it has to talk to other processes to get things done, or what's up with all this waiting? Does anyone know?

> They are providing a system that is completely under the control of a central authority.

That could be the dictionary definition of the opposite of end-to-end encryption. Since the claim is that it will be e2ee, I'd assume they at least make an attempt to meet the definition and subvert it in some other way.

> Every additional step required to set up a chat ...

Nobody was arguing that it should get in your way. Again, see the alternative app I mentioned as an example of how it can be done: in Threema it also doesn't get in your way, you also have to go into the user's profile to do the verification, but the status is displayed while you're chatting rather than being just something ignored in a back menu for super nerds.

Oh just that little message saying that the safety number changed? I thought it would actually, like you said, start bugging you to verify the safety number upon "sudden" changes.

I'm confused, what is it that you're trying to say? None of it adds up to "you are trusting the server" and all of it (except the part saying that you're necessarily trusting the server) is exactly my understanding.

> The umbrage that the GP seems to be taking is that Signal doesn't require you to verify your key, nor is it particularly visible.

Only the latter really, but yes. It doesn't need to be required -- see the footnote text where I elaborate: Threema also doesn't require it, but it's very visible, so people do it and thereby avoid having to trust the server.

> only really starts bugging you about verifying keys if they suddenly change

Does it? I haven't seen that, though I think the only key changes so far have been in group chats, perhaps that's different. This would be quite an improvement over WhatsApp that I wasn't aware of (if it really does this).

This is indeed what I meant. Of course it's encrypted by default, but unless you verify the keys, you're trusting the server to be honest which is not the point of end-to-end encryption.

Because you can verify keys, the chance of them getting caught inserting interception keys is pretty decent (if a small % of users does the verification), so they're quite likely to remain honest and anyone who might hack a Signal server would also think twice where the gain is worth triggering this indicator of compromise.

I wonder if they'll make it unverifiable (like Keybase[1]), opportunistic (like WhatsApp[2]), requiring confirmation in every call so nobody practically uses it (like Telegram[3]), hide the key verification screen so 0.001% practically does it (like Signal[4]), uses long-lived keys that can decrypt all historical traffic (like PGP), have encrypted mode be some second-rate mode that removes most of the features you need (like Telegram's encrypted chats; I see that the announcement already mentions some unavailable features when you turn on encryption), or if they'll have a novel trick to break the encryption at will. At a minimum, I expect it'll be an obfuscated binary with auto-updates and no published independent code reviews.

Let's hope Microsoft surprises us all! (as I see most of the comments being skeptical)

[1] Try to verify which encryption keys your mobile keybase chat client is using or if the server injected its own keys. Bonus points if you spot the "this chat is end-to-end encrypted" banner while you're doing this. Details: https://security.stackexchange.com/questions/222055/how-can-...

[2] You have to go into settings to enable even just seeing key changes, let alone that the client stops you from sending messages when a previously verified key changes.

[3] Telegram calls have encryption, but every time you have to verify the emojis again and again instead of it just storing the other party's key.

[4] Threema shows the verification status for every chat. My mother in law, from her own volition, wanted to verify keys with me. She later tried Signal to compare, since she needs to use something encrypted for her work (medical data), but didn't get that she had to verify keys on Signal, too. I find that even techies often don't know where to find that in Signal, or even realize that it's required for the security claims to apply.

That is fair advice, thank you for this reply (sincerely). I wouldn't describe this as burning out, for what it's worth, but I do see what you mean.

Yeah, that's fair. I think FileZilla shows who signed the cert, but yeah it still gives that pop-up asking the user to decide and I haven't checked whether they verify that signer against the system CA list. Either way, that's as canon as FTP clients get and since they don't have it, indeed it's mostly opportunistic encryption. (Not that relying on the CA system rather than TOFU'ing or sharing a fingerprint is without problems of its own, but that's a discussion for another thread.)

This discussion isn't constructive. To reflect on how I interpret what you write: first the complaint is that one can't self-host it when the post already contained a github link, then that it doesn't have a share app when in fact it does (at the same link that I now posted a second time), and now that I shouldn't be running an open source project altogether. Perhaps judge whether I am suited for running this by how I treat your contributions when you make them. Otherwise, there's always that fork button!

Again, I already wrote:

> though I still have to change the license to be more permissive (I've decided that I won't pursue this as a commercial thing, just open a ticket if you want me to change the license sooner than whenever I work on this next).

Guess that'll have to be now then. Getting this sort of crap is what makes me wonder why I bother putting this work out there in the first place.

> Your tool has none of the requested features

The main premise was a way to have file sharing between tablets, phones, and computers. This does that. It is open source (as of now) and has an Android share app to boot[1]. Anything else you're very welcome to make yourself, it's not a commercial plug, I'm obviously disclosing my affiliation, I host this on my personal machine at home, you're just welcome to make use of this or not if you don't like it.

[1] https://github.com/lgommans/dro.pm/tree/master/android/dropm...

It starts to become a little repetitive, so I'll cite from what I replied to the sibling comment:

> Should I package it as a .deb, or what makes something self-hosted? The code is already on github: https://github.com/lgommans/dro.pm/ (link was buried in the text - I had a hard time prioritizing what people would want to read first, since that depends on your use-case).

As for no mobile app: how much faster is it going to get than opening the browser that's already on everyone's homescreen and typing a 7-8 character link? Or if you self-host it, you can host it on your own TLD like https://me/. It being an app was also never mentioned as a requirement and I don't see how it helps, but I guess I don't need to understand. As a bonus tip, though: you can add browser bookmarks to your homescreen. Since you'll need internet to share things in the first place, it should behave roughly the same (aside from a share menu, but...).

And there is a share modal for Android, actually. See the github link.

Should I package it as a .deb, or what makes something self-hosted? The code is already on github: https://github.com/lgommans/dro.pm/ (link was buried in the text - I had a hard time prioritizing what people would want to read first, since that depends on your use-case).

I guess magic wormhole is the wrong context to be making this argument in since everyone's primed for peer to peer now, but in general, yeah when using dro.pm it will put your data on dro.pm, similar to how pastebin stores your data when you use pastebin. It otherwise (and that's why I made this design decision) couldn't work after you close the tab, making it much less suitable for most of the intended use-cases. If you want peer to peer file transfer, you could have a look at https://file.pizza (not made by me)

If you're running FTP as plaintext you're indeed doing it wrong, I'm not sure that that must be what GP meant. Not as if we explicitly mention (START)TLS for every other protocol that supports it.

I made https://dro.pm for this. You get a link like dro.pm/h which is short enough to even share over the phone or tell someone at a conference to open. Not like chat apps where you have to be connected to the other person first (even if that is yourself, need to navigate to that chat) and no need to install any software. It's made to be fast on any connection (e.g. by allocating the link before you even entered any data), and due to being ephemeral it's also less prone to being used for phishing like other link shorteners are.

It auto-detects when you enter a link, otherwise treats text inputs as a pastebin, you can ctrl+v an image, and it has file uploads up to a few gigabytes. Code is on github (https://github.com/lgommans/dro.pm/) though I still have to change the license to be more permissive (I've decided that I won't pursue this as a commercial thing, just open a ticket if you want me to change the license sooner than whenever I work on this next). Viewing uploaded files instead of downloading is also possible for image/audio/video mime-types by adding /preview to any link.

You can also use it from the command line if you're on a keyboard+terminal-only machine, e.g. just `wget -L dro.pm/h.txt` to download the uploaded file (the links accept an arbitrary .extension) or for uploading from the command line there is a bash one-liner contained in the page source itself, see: `curl https://dro.pm | head`

Made a mistake and uploaded something private or want to edit the link? Just click delete on the website, or on the command line you can use the token that you get when creating a new link.

Six hours ago I was trying to figure out CPU vs. GPU performance with memory-hard algorithms and ran into a wall when hashcat turned out not to support argon2 at all and scrypt modes only up until 16 MiB of memory.

Looking a bit deeper, someone had opened an issue about that 28 days ago and 19 days ago a patch was committed to master that should support a cost factor of up to 1M (which would use 1 GiB of memory at the recommended block size[1]). Given the slow release cycle and my having a talk on the topic next week, I downloaded the hashcat source, compiled it, struggled a bit more with the driver (switched OSes because compiling for Windows seemed like a ring of hell I wasn't yet ready for, so needed a new driver installation) and... now they just release the binary! Could have saved that effort, but oh well. Now, instead of erroring out at 16 MiB, it errors out at 110 MiB, saying not enough allocatable memory (it says on startup that the GPU has 6949M allocatable) and at 114 MiB it gives an error that, when you google or duck it, actually gives zero hits.

The speed boost of scrypt in this release is about 5 times in my benchmarks, but note that the old release was run on Windows and the new release on Linux, so driver differences probably affect that as well.

So that's my highlight of this release: better scrypt support. People that were using memory factors above 16 but below 110 MiB, beware! (Not that 64 < memory_usage < 128 MiB are valid and usable in many (most?) implementations, but hashcat runs with it.)

Of course, the real strength is in the password, but you know your users...

[1] 128 * r * N, where r is the block size (recommended to leave it at 8) and N the cpu/mem cost factor, via https://stackoverflow.com/a/30308723/1201863

Note that Keybase never offered end-to-end encryption, they tried to solve it with blockchain magic and, granted, got quite far (what they made truly was innovative), but missed a tiny step of actually checking the blockchain (which would be resource-intensive for mobile devices, which is why they pushed it back for later solving) or offering any other way of verifying the encryption keys.

I actually reached out to Keybase as well as one of the NCC auditors that I've talked to in the past for unrelated reasons, but the auditors are playing deaf and Keybase (on the third contact attempt) claims it's safe because of the decentralized social proofs (which aren't actually verified by the app -- you trust solely on the Keybase servers to give you the right encryption keys). All details are here: https://security.stackexchange.com/questions/222055/how-can-...

The whole thing seems moot now that Zoom bought them, but so now if Zoom does anything with blockchain and supposed end-to-end encryption, I'd be very weary and verify things regardless of whether it was audited. Even as a user, you can make sure they covered the basics (from my StackExchange post linked above):

> Users should have demanded followable instructions. We should have questioned Keybase, now Zoom, and anyone who makes a strong security claim. They claim it? You should want to see steps you can follow to verify it. Since you put your trust in the published code, those instructions should not involve any command line coding work, and definitely not have gaps like verifying keys on your laptop and hoping that the server sent the same keys to your phone.

This doesn't satisfy either requirement: "encrypted video stream" most importantly, but also "[using a] plain file host rather than hosting some custom service" since a plain file host won't pull my https stream, I'll need to setup another service to do that. Or did I misunderstand what you meant? Either way, thanks for helping think of solutions!

> Unless the remote system (where the video is being received) is untrustworthy

Well, that's part of the threat model. There is no need to trust the remote end fully, especially since I'm hoping that I can host at Google / OVH / Hetzner / whatever. I trust them as a backup and not to collude with a burglar, but why give them plaintext data?

... To answer my own question, not adding encryption makes life easy I suppose... but that's not very satisfactory imo :)

ZoneMinder doesn't do encryption, not sure if it would allow adding in gpg as a plugin somewhere.

Network bandwidth is generally not metered on home connections, so that's indeed not an issue, but storage isn't infinite. Transcoding the video would be a plus and can't happen remotely due to encryption. Raw mjpeg is also an option though, storage isn't that expensive (or throw more CPU at the encoding system; a raspberry pi is just an example).

> encrypting the network traffic end to end

but the video stream? The idea is that the storage server (Google, for that matter) doesn't need access to my video stream. Not sure if end to end encryption is too much to ask but I did figure since it's 2020, it should be doable.

Thanks for your responses by the way, it's helpful to have a second pair of eyes on finding a simple solution. Since there doesn't appear to be one, I will start experimenting with some ideas, feeding ffmpeg to gpg and checking cpu vs. compression ratio etc. Next step will be seeing which protocol to use for local + remote writing of the encrypted file (not sure if sshfs does incremental writes / appends). Let's see how hard this is! :)

> you mean to encrypt the stream itself?

Yes.

And indeed Debian (raspbian) has a ton of components that I can string together, but it doesn't appear entirely trivial to make a low-powered system encode (h264 is expensive by itself) and encrypt a video stream of a decent frame rate and resolution and upload it to a standard file host, all close to realtime (perhaps up to ~4 seconds delay, that should be fast enough even if the intruder knows about the cam (Kerckhoff's principle) and immediately moves to pull the plug).

I don't think it can be done with entirely off-the-shelf components actually, it probably requires quite a bit of glue to make the components work together, cleanup files (locally and remotely), etc., but I'd be happy to be told I'm wrong :)

Edit: did you edit this in?

> if all you want to do is upload image files

Well kinda, but multiple images per second and preferably with some delta algorithm so they're not 100k×86400×fps = something on the order of 50GiB/day. A h264-compressed stream is an order of magnitude smaller. (Sunrise is the worst, increases the stream size by ~3×.)

> Could be as simple as mounting the remote server via sshfs

Right but that's not encrypted and requires me to maintain another server. With unattended upgrades it isn't much, but it adds up if you have ten other things already running and you're actually trying to downsize this time commitment (mainly for the major version upgrades which take days out of holidays every few years, upgrading and re-testing everything again, sometimes fixing dependency issues, reinstalling things...).

Storage can be an "as a service" thing these days, indeed Google Drive / OVH NAS / hosted NextCloud / HiDrive / etc. is what I meant, basically anything that could interface with a pi in a way that it uploads the encrypted stream, so you capture whoever unplugs it -- at least that's how I imagine a regular security camera would work. But then, the only things I find online start at 4 figures and none of them are open source so who knows what encryption (if any) they really apply... Is there really no one on this planet running open source encrypted cameras, are all these systems that consumers use (some of whom are hackers) 100% proprietary, plaintext, or only stored on-site?