Hasn't this already been done? (a list of similar utilities for comparison)

[schollz]

Hasn't this already been done? (a list of similar utilities for comparison)

[anarcat]

i'm also concerned that croc does not use PAKE like Wormhole, which means passwords are much easier to guess than they should be.

[FrontMage]

I think maybe it's because wormhole is not easy to install on windows?

[anarcat]

i am also curious to hear why croc exists, especially since the author seems to be aware of magic-wormhole. i think we should avoid fragmentation in this sector and make sure all wormhole-y clients share a common infrastructure or at least interoperate. maybe it would be possible to use the normal wormhole servers for this?

if not, then we'd need some sort of federation to have things make sense again: magic-wormhole/magic-wormhole#72

otherwise it's kind of a shame if we have yet another non-standard way of sharing files... again... :/

[schollz]

@anarcat

i am also curious to hear why croc exists

croc mainly exists because I wanted a executable magic-wormhole-type program. The Python installation is not easy for someone who isn't very familiar with a computer.

i think we should avoid fragmentation in this sector and make sure all wormhole-y clients share a common infrastructure
it's kind of a shame if we have yet another non-standard way of sharing files

I disagree. I believe most services benefit from having alternatives, so we are not reliant on a single centralized source.

i'm also concerned that croc does not use PAKE like Wormhole, which means passwords are much easier to guess than they should be.

I don't think this is true. Here's why: In both wormhole and croc all you need to guess is the code phrase. In croc the relay stores a SHA256ed code phrase, whereas Wormhole stores a PAKE-encoded code phrase - and both of these are still basically impossible to determine unless you know the code phrase. In croc the code phrase is mnemonicoded random 4 bytes, which means you have a 1-in-4,294,967,296 chance of guessing the right phrase each time. Actually the default in wormhole is a 2 byte code so an attacker gets a 1-in-65,536 chance of success for guessing the code. So I could say the opposite - its easier to guess in wormhole using the defaults.

However, this is also not really that important because both croc and wormhole are meant for transferring immediately between two people. It would be very hard for an attacker to enumerate very many possibilities when the attack space in time is so small. So it doesn't make a huge difference in either case.

That being said, I'd still be open and happy to have PR request for implementing PAKE instead of the SHA256.

[anarcat]

On 2018-06-22 06:38:30, Zack wrote: @anarcat > i am also curious to hear why croc exists *croc* mainly exists because I wanted a executable *magic-wormhole*-type program. The Python installation is not easy for someone who isn't very familiar with a computer.

I understand the idea behind Golang static executables, and I think that's a great idea... :)

> i think we should avoid fragmentation in this sector and make sure all wormhole-y clients share a common infrastructure > it's kind of a shame if we have yet another non-standard way of sharing files I disagree. I believe most services benefit from having alternatives, so we are not reliant on a single centralized source.

... however, I don't understand why a different protocol was implemented. Even if you didn't want to use @warner's servers, you could still have stuck to the protocol he established instead of rolling your own. This would have ensured the two projects are compatible in terms of line protocol. It's great to have alternatives and I find the idea of running extra wormhole servers great, but I don't see the need to implement a different protocol.

> i'm also concerned that croc does not use PAKE like Wormhole, which means passwords are much easier to guess than they should be. I don't think this is true. Here's why: In both *wormhole* and *croc* all you need to guess is the code phrase. In *croc* the relay stores a SHA256ed code phrase, whereas Wormhole stores a PAKE-encoded code phrase - and both of these are still basically impossible to determine unless you know the code phrase. In *croc* the code phrase is mnemonicoded random 4 bytes, which means you have a 1-in-4,294,967,296 chance of guessing the right phrase each time. Actually the [default in *wormhole* is a 2 byte code](https://magic-wormhole.readthedocs.io/en/latest/welcome.html#design) so an attacker gets a 1-in-65,536 chance of success for guessing the code. So I could say the opposite - its easier to guess in *wormhole* using the defaults.

PAKE is specifically designed to establish a strong session key with a weak one-time secret. What you are describing is the weak one time secret in Wormhole, and I do not believe it is easier to guess a wormhole code than it is to guess a croc code, because the codes are disposable. I haven't studied the details of how croc implements its key exchange, but that's exactly the point here: the PAKE protocol used by Wormhole has well-known properties which do not require me to audit the entire protocol every time a new project comes up. By rolling your own key exchange, you possibly expose croc users to attacks PAKE were designed to work against that you might not have thought of. For example, reading this description from the README:

The code phrase for transfering files is just three words which are 16 random bits that are menemonic encoded. This code phrase is hashed using sha256 and sent to the relay which maps that hashed code phrase to that connection. When the relay finds a matching code phrase hash for both the receiver and the sender (i.e. they both have the same code phrase), then the sender transmits the encrypted metadata to the receiver through the relay.

... make me worried that an attack against croc could be simply to create a rainbow table of possible all possible SHA256 keys and transmit those to bruteforce a channel and access the content.

However, this is also not really that important because both *croc* and *wormhole* are meant for transferring immediately between two people. It would be very hard for an attacker to enumerate very many possibilities when the attack space in time is so small. So it doesn't make a huge difference in either case.

Well, the reason this works on Wormhole's side is that the attacker has only one try, so even though there are 65k combinations, the odds of succeeding on the first try are very small. It is not obvious to me that this is how croc works as well, but I might be mistaken! :) Again, this is why a different implementation is problematic: its security properties are unclear and users are left to try and figure out exactly how the thing works...

That being said, I'd still be open and happy to have PR request for implementing PAKE instead of the SHA256.

I think that would be a great idea! @warner said he would very much like to have a golang implementation of the wormhole, and I think it would be awesome if croc would be compatible. You wouldn't have to reuse @warner's servers (in fact he might not even want you to) but at least if the protocols were the same one users could use the two software to share files between each other.. It's hard enough as it is to convince people to install "the right software" to download stuff, let's not make it even harder for them... ;) Thanks for considering my comment and for your repsonse! :)

…

-- Music gives a soul to the universe, wings to the mind, flight to the imagination and life to everything - Plato

[schollz]

@anarcat Please combine this discussion and your other into a new issue for croc

[anarcat]

sure, done in #71