21–30 of 65 posts
"Secure" but "we advise against using Bitfly for highly sensitive data. You have been warned.". So is it secure or isn't it?
From the HN title: "secure" I have a question: Secure against what thread model? The FAQ has an entry for "How do I know you're not sending all my data to the NSA?" but that's the wrong question to ask (i.e. Even if you're not behaving maliciously, that doesn't mean our data is safe against highly sophisticated threats). It would really be great if you could demonstrate what makes this more secure than alternative so…
Earlier quoted context omitted.
These are very good points. I believe that adding any real crypto to the JS code to be a doomed path so I probably won't go for that. My only argument right now is couldn't one verify that the IP of the recipient is the same as the address of the expected receiving device (or router) and be somewhat sure it's not MITM?
The way I would make this work: - Build a DHT style overlay network of "meet in the middle" servers - Have a standalone html file, that uses websockets to connect to the network of servers. - Have both clients generate keys, exchange them via other channels. - Both users have a shared key, they both lookup the server that hosts the shared key on the DHT network (that actually can be done without leaking the key to ev…
Earlier quoted context omitted.
A big problem is that webRTC is highly MITM-able. You have to exchange initial connections using a server. So no party has any way of knowing if you are MITM attacking. You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels. But all-in-all this does not offer ANY security…
These are very good points. I believe that adding any real crypto to the JS code to be a doomed path so I probably won't go for that. My only argument right now is couldn't one verify that the IP of the recipient is the same as the address of the expected receiving device (or router) and be somewhat sure it's not MITM?
Mega[1] users JS based crypto and it's been fine
[1]: http://mega.co.nz
With some sort of peer discovery functionality, this could be a pretty cool open, cross-platform replacement for Apple's AirDrop. ...but would probably need WebRTC functionality in Safari to work on iOS devices
I mentioned it in another comment upthread, but http://sharedrop.io is exactly this. WebRTC file transfer with LAN peer discovery.
I was wondering if it is possible to transfer streaming video data over WebRTC already, for example to implement a video chat service, without wasting too much CPU power and/or bandwidth?
Similar project: FilePizza – https://file.pizza/ github: https://github.com/kern/filepizza show hn: https://news.ycombinator.com/item?id=9535332
ps: although it says the HTTPS connection is not safe.. weird. pps: lazy me would love a multiple file options ..
From the HN title: "secure" I have a question: Secure against what thread model? The FAQ has an entry for "How do I know you're not sending all my data to the NSA?" but that's the wrong question to ask (i.e. Even if you're not behaving maliciously, that doesn't mean our data is safe against highly sophisticated threats). It would really be great if you could demonstrate what makes this more secure than alternative so…
Webrtc itself requires perfect forward secrecy. While you cannot do authentication with it - you need to provide that yourself - you can be certain besides yourself and whomever your signaling server told you is your peer are the only two able to decrypt the packets going between you two.
Therefore, can't they download the sample just like the connected client?