First off, this looks like a nice project. So please take this as constructive criticism:
1. This really should have screenshots published. Especially when comparing with something polished like AirDrop, the UX is important. You even call this out as one of the features, so it's really odd not seeing the screenshots to support that statement.
2. "Uses state-of-the-art cryptography algorithm" isn't very reassuring. It would be nice to know what standards your using, maybe some details about the underlying protocol.
3. For Android, please consider publishing in Google Play or other stores. I'm not going to enable "untrusted sources" and install a random APK off the Internet.
1. Yeah. I should have had screenshots on my webpage :).
2. It's Chacha20-Poly1305-IETF. I haven't have time to document the protocol, so if anyone wants to see it, they need to read the code :).
3. Yeah, that's also in the plan.
My point is that average people might not care about the exact algo being used. They might not even care that it's actually encrypted, so there is no need to specify it in the homepage. The only point of documenting this might be just for devs or people who wouldn't use before they know how it works.
I agree with you, the details on the frontpage are enough for 99.99% of users, but IMO security is something that people rely on "trusted sources" so having somewhere easily accessible for these "trusted sources" to learn how it works, helps, specially when a project is new.
After a while people just "know" that signal is secure not because they know how it works but because they heard enough "trusted sources" describe signal as such.
I have little experience with cryptography, and have no idea whether it is a good choice or not.
If it is, how would you convince regular people that the state of the art “something something sodium chachacha” crypto algorithm in the app is the best for them?
It might be better not to mention the name.
Some stats would be nice, like: your files would take X years to decrypt if stolen (backed by some trusted sources).
> I have little experience with cryptography, and have no idea whether it is a good choice or not.
libsodium is from DJB & Tanja Lange, it doesn't get better/more trusted than that without preferring to trust some state entity of choice. (For some reason ranging from regulatory requirement to hopelessly misguided.)
> If it is, how would you convince regular people that the state of the art “something something sodium chachacha” crypto algorithm in the app is the best for them?
Personally, I'd make a separate page with more details for the subset of folks who are interested. It doesn't need to be on the main page, but at least something to reassure technical users that the project hasn't rolled it's own DIY crypto would help. :)
You could have "state-of-the-art cryptography algorithm" as a link to a page with more details. Or just put the name of the algorithm in brackets afterwards, e.g. "state-of-the-art cryptography algorithm (ChaCha blah AES blah)".
Re 3. This is from the repo under control of the author. What makes you think that you will be safer if the author submits the same apk to the google store?
Google does some vetting. Also, if the author doesn't get in first, someone else could put it in the store, claiming the name and making it hard for the author to update.
Glancing at your crypto implementation[1], it seems to contain newbie mistakes - eg no public key crypto involved in your public keys, usage of low level raw crypto algorithm primitives from libsodium without session, replay etc related security concerns, no signs of design requiremnts re what security guarantees it's trying to provide, no PK key management, etc. You're also hand rolling wire protocol code in C++, manipulating raw bytes and lengths, which is a receipe for memory safety vulnerabilities.
Use an pre vetted implementation of a good security protocol for this, or if this is a hobby project, spend some time reading up on crypto protocol design.
If you feel like throwing "newbie" accusations around, it'd be prudent to back your list of grievances up with more than a single link to crypto.cpp. Chances are you misread the code, didn't grok what the op was doing, etc.
As it stands your comment reads like a common variety abrasive and dismissive gatekeeping... rant, basically, which is unfortunately so popular in crypto circles.
Edit - the project does dearly need a crypto spec. "Uses state-of-the-art cryptography algorithm" claim begs to be described to be valid.
Crypto people: “programmers really need to get better at using crypto!”
Also crypto people: “how DARE ye mere mortal even touch crypto!!!”
This doesn’t help. The only people who will listen to “don’t roll your own crypto” are the very people who ought to be learning how to do it. The arrogant types who should never touch crypto will ignore this advice and still write bad crypto.
The most effective thing would be to just tell programmers why crypto is hard in ways other code is not.
Crypto is hard because you can’t simply unit test for vulnerabilities. “Anyone can write a crypto system they themselves can’t break.”
For the majority of code it’s good code if it works and is fast and lacks things like memory safety bugs.
For crypto it can work perfectly and still be grossly insecure. The only way to tell is to deeply understand cryptanalysis and do academic mathy stuff.
As a result if you use crypto it’s best to write boring conservative crypto and use it the way pro cryptographers suggest. Try to use a peer reviewed library or if you can’t and must implement then try to ape a peer reviewed library exactly.
Don’t even try to invent new stuff in crypto unless your understanding is very thorough and don’t use anything new without peer review.
Edit: another example of abnormally hard code is distributed databases. They can be unit tested but adequately doing so is extremely difficult. It’s easy to write one that seems to work but loses data at scale or under edge case failure scenarios. Crypto is even worse.
Well, it's about 2 screefuls of very simple code. Eg for the PK part, if you ctrl-f for publicKey and remotePublicKey, you see there are no usages that could plausibly be doing public key crypto or PK key generation based on crypto 101 from school.
Not sure how to respond about gatekeeping. What do you think would be a good way to write a comment pointing out these kinds of security problems? Or do you think it's unfair to do it at all?
I’m not sure what you mean by there being no public key cryptography here. In the Crypto constructor, a random secret key is generated, and then the generator for Curve25519 is scalar multiplied on the elliptic curve by this secret key to generate a public key. That’s the standard process for X25519 key generation, and it’s what Libsodium does to generate a secret key/public key pair [1].
To establish a shared secret session key, the standard ECDH procedure is used, as seen in Crypto::setRemotePublicKey, where we multiply the other party’s public key by our secret key on curve25519 to establish a shared secret. This shared secret is then used for encryption, since symmetric encryption is generally cheaper + more secure than asymmetric.
I absolutely agree that this project needs a more formal cryptographic approach, and should be using a higher level construct (e.g: crypto_secretstream, also from libsodium), but as far as I can tell at first glance, this is a working implementation of X25519.
The reason I "rolled my own" key exchange is that I'd want to use the IETF variant of Chacha20-Poly1305 in my protocol and there doesn't seem to be helper functions for key exchange for this algo.
Unless I'm misunderstanding you, the crypto_secretstream construction [1] that I (and others) have recommended uses ChaCha20Poly1305-IETF as its symmetric cipher. There wouldn't be a key exchange for this algorithm, since it's symmetric. However, the crypto_kx functions [2] generate a 256 bit shared secret, which should work for a ChaCha20Poly1305 key I believe?
Probably should have used higher-level functions. Maybe next time :). I don't think I can change the protocol and break compatibility at this time lol.
The crypto_kx functions seem to generate 2 symmetric keys for 2 directions. That creates complications in the code and that's why I didn't use it initially..
Yeahhh, that's a fair point about unnecessary complexity. The docs say if only one symmetric key is necessary, you can just set one of tx/rx to null, and the other will still be the requisite 256 bits, but I appreciate why that's a bit ugly.
Just point out the attack vectors, with some reference on solving those.
No need to "you're implementing things yourself. bad. use someone else's library". That is gatekeeping indeed, and a rather insulting way to express your concerns.
If you simply demonstrate the complexity of dealing with all security concerns, they'll realize what they need. Prepackaged "always do this" does not teach well.
> Edit - the project does dearly need a crypto spec. "Uses state-of-the-art cryptography algorithm" claim begs to be described to be valid.
It does not need a spec. It just needs to put a small print on "algorithm" and mention that it is using a cryptography library called libsodium. That's it.
As for the armchair field marshal cryptographers ranting around and nitpicking "useful projects", they are the same ones who praised Signal for their actual "state-of-the-art cryptography algorithm" for end-to-end encryption until they added a cryptocurrency coin in the messenger. Same with Keybase.
At least this project does not have such frivolous features and is only using libsodium like everyone else.
It is very easy to give "expert" criticism (constructive or not) on an open source project (since the project is transparent) but it is much harder for the critics to dive in and fix the aforementioned issues themselves. I would have much more respect for those who do both.
A great starting point to learn about crypto is to first study current best practices until you understand exactly why they are best practices. Then go through a list of vulnerabilities that have been found in flawed algorithms or constructions and try to understand how each of these vulnerabilities works. Keep digging into these rabbit holes until you feel like you have a grasp on what a good construction looks like and common pitfalls.
Yeah I've also done my research and found a lot of similar stuff. The problem with this particular one is it requires Internet* to work. I don't feel good about WebRTC and having to share my public IP address for such a task.
Also, it requires you to open a webpage every time you use it. I'd really like the user experience of AirDrop that you need to do nothing to receive files. So I made LANDrop a daemon-like stuff.
* It has a mode that you can save the page offline, but that doesn't work with iOS.
I agree completely with @tjohns first point, if you're calling out UX as a top point then you really should have screenshots. You should have screenshots anyway.. I dislike having to download something just to see what it looks like. Not having screenshots just makes the barrier to entry higher.
Second point, you really need to make sure spelling is correct (i.e. "celluar" should be "cellular"), that degrades the perceived quality of the product. If I see spelling mistakes on the landing page then I assume there might be other kinds of mistakes... like in the codebase for instance.
Thank goodness for this. A true cross platform alternative to AirDrop, Dukto and Dropcopy that actually works everywhere. Not a dreadful Electron app and also works on mobile devices as well and best of all is open source.
No walled gardens, no subscriptions and no deliberate limitations on number of devices.
Some good comments on cryptography that I will probably bookmark and use to study in the future, but as an end-user, I've been hoping for years on a local-network-only solution that basically works on all platforms. Functionality-wise, cryptography can shape up in time whereas I can use these non-trivial features today. Bravo for the privacy-conscious approach and development of apps closer to native. I tested it in these directions and double checked with sha256sum:
- Mac <==> Mac (Wireless)
- Mac <==> Mac (Thunderbolt 4 Bridge)
- Mac <==> Android
- Mac <==> iOS
- iOS <==> Android
Features I'd have interest in:
- Choose interface/IP address to listen on by default instead of all interfaces (can still be first-time default). This helps prevent accidentally sending over a not fully-trusted network. I imagine that with the next iPad supporting Thunderbolt 4, it could be easy to send over wire. This also helps smoothen someone's lack of confidence in the network security of the app. You also probably already thought of this since there is an "Advanced" section which currently supports changing the port
- Have some way to verify the target's IP address for the Flutter app on iOS and Android prior to sending
- A command-line interface to automate sending and receiving
Just tested out with my iPhone to Ubuntu 20.04. Works nicely with photos. Tried to sending some videos (iPhone to Linux) and some of them fail. A short 30 second video worked fine but longer 4 and 8 minute ones failed. Those longer videos may have also been stored on iCloud and not locally. Within the iOS app it doesn’t “select” the longer video files to be able to send them.
Hope this helps. Nice tool and I can see myself using this if these issues are sorted.
There're a few such tools, e.g. TrebleShot and NitroShare. Does this improve something over the current solutions or is an alternative? Also Snapdrop and ShareDrop are two web apps offering similar functionality. Good choices in case someone doesn't want to install anything.
I've done my research and also found a lot of similar stuff. They are all not as convenient as AirDrop, so I wanted to make a thing that's close enough.
I used Resilio Sync (ex BTSync) to transfer between devices, but it's not open source and by default allows to use "relay" servers: https://www.resilio.com/individuals/
Sharing from win10 to iPadOS (14.4.2) was very flakey. Installed the app on PC and tablet easily, however win10 couldn't see the tablet unless I restarted the app each time.
After understanding the workflow, sending files was pretty slick, but janky.
I suspect the iPadOS app is only announcing when it opens for the first time.
Great effort here. Agree with others re UX and the unsigned APK. I currently use Syncthing to fulfil my LAN file transfer needs. It's not quite the same but it does have a bunch of other use cases which I like, plus it's well-known, well-supported, also open, and I trust it.
Does it work over WiFi direct.. meaning I can send a file to someone on Android without them being on the same WiFi network? That is the primary reason I find AirDrop so useful.
First impression, this looks nice! But on Linux dragging a folder into the file box doesn't work, that's a pretty simple but important feature IMO. Good work!
Looks neat, nice work. I would suggest changing the download links to have more affordances that they're clickable, it just looked like a table of version numbers to me at first and I didn't realize they were links at all.
I don't get the mindset where you finally ship but botch the launch marketing. The window of opportunity is so small and rarely comes back, that you really need to get the basics right, e.g. closely monitor launch posts, answer within minutes, be truthful, thank people if they provide useful feedback, etc.
Syncthing requires setup on both ends, and then automatically keeps two complete folders in sync across a network (local or internet), conceptually similar to a network file system.
This only requires having the app installed on both ends, and then manually send & receive individual files on-demand (over the local network). It’s more on the level of peer-to-peer instant-messaging.
- It's mainly me and some friends that does non-code stuff. No companies involved at this moment.
- No cloud service is used. Your app doesn't connect to the Internet. See the privacy policy.
- :) will post screenshots when I have time.
Ah cool, no company involvement makes it much more interesting to me. Because sooner or later they'll always want to monetise and that has privacy impacts generally.
I missed the internet part, sorry! It doesn't say so explicitly, just that the info is not collected. But how do the peers find each other then?
1. This really should have screenshots published. Especially when comparing with something polished like AirDrop, the UX is important. You even call this out as one of the features, so it's really odd not seeing the screenshots to support that statement.
2. "Uses state-of-the-art cryptography algorithm" isn't very reassuring. It would be nice to know what standards your using, maybe some details about the underlying protocol.
3. For Android, please consider publishing in Google Play or other stores. I'm not going to enable "untrusted sources" and install a random APK off the Internet.