[lan_encrypt_data - UserGuide wrong or name idiotic?]

IIRC the MOD address space 25/8 is assigned to them but it's used on private networks without direct internet connection.

Pragmatically it's used just like 10/8 but actually belongs to the MOD instead of the IANA and you're only likely to run into problems if you connect your machine to an MOD network ... that's probably illegal and will earn you a stint in a military jail.

So it's probably safe unless someone else notices... https://blog.wireshark.org/2010/04/t-mobile-clever-or-insane/

NB: 192.0.2.0/24 is also unrouted and reserved.

NB: Unlike 14/8 which used to be a lot like 10/8 but was rarely used and is now allocated to APNIC.

NB: The best is 240/4 these addresses are all unallocated and can be used for any private use you like ... except Windows; Microsoft windows considers these as illegal addresses!?

[Chain of trust]

This is all about certificates style authentication.

The Certification authority signs everyone's private certificates and the peers validate each other's certificates before they make a connection. Nobody (not even the CA) gets to see anyone else's private certificates so they cannot pretend to be each other. A 'kicked user' list (normally called a certificate revocation list) can be circulated to say what signed certificates are no longer trusted, it's normally also signed by the CA so only the CA can create a valid revocation.

As every peer has a unique ID (certificate) the peers can make sure they only accept a certificate from a single IP and they can tattle to the CA if they have active connections from multiple IPs for one certificate.

Having described all that, I'm not sure I'd really want it. There will be times when I want to work in the current fashion where you can publish the read only (or even the RW if you're brave) key to all who may be interested. And frequently, all the hosts for a secret share will be under the same control so a shared secret authentication is the simplest solution and hence the best solution.

But if you're going to use certificates, or a kind of "plugin" authentication scheme, the very first thing you must do is to detach "identification" from "authentication". What this probably means, in concrete terms, is to separate the "info hash" from the "secret". eg: The "info hash" would be a hash of "Tom's private document store created 12/12/13" the secret would be "b0227da3e6105bb5546d9d0f00a9bc23" and they have no relationship to each other what so ever.

[.SyncIgnore is great but...]

Some more technical details to understand the case. SyncApp makes sure that file tree is the same across devices, in this case one computer reports that it has a file, and another says it doesn't have it (it is in .SyncIgnore). SyncApp can't have separate file tree across devices, so there are two options: delete file, or get it from the peer. Both actions are undesired, so having similar .SyncIgnore across devices is the only right way.

This is why I said it might be better to consider it as a redirect.

So if a file "thefile" exists in .SyncIgnore it's redirected to be stored into ".ignored/thefile" as far as the shared tree is concerned nothing changes but if this node downloads a file it'd store it in the .ignored directory not the original location. Of course as it is being ignored we don't actually want to download it, but under this view of the world that is just an optimisation. (eg: We'll download it tomorrow)

When a file is added to the .SyncIgnore it would not be added as a local delete but as a remote create, that way the shared file doesn't get deleted.

[.SyncIgnore is great but...]

I'm not sure I quite follow? What's wrong with having the .SyncIgnore file on BOTH devices being identical and ignoring, in your case, "*~", "*.bak", "*.o" "*.iso", and "*.sh"?? ...that way, none of those files will sync between devices.... which is what you want, right?

Okay, here's the full use case:

Think about THREE machines not just two.

I want most of the files to go to all three machines.

It's a directory containing source code so I don't want the object files to sync because the machines have different processors so the .o files are incompatible.

Some of the files are a test suite with some huge test files, this isn't required on one of the machines (and wouldn't fit anyway as it's a little NAS box) so I don't want them on that machine. But I still want them on all of the others.

Now I setup the ignore files, the *.o files are easy.

The test suite has to be ignored on ONLY the NAS box.

Oh, it looks like the Windows box uses *.obj not *.o so it would be reasonable to ignore those on just that one.

You see it now ?

[Sync to Network Drive ?]

Just a warning on this; syncApp is continually watching the drive. I don't know if it's using change log on a local NTFS drive but even if it is it can't use it on a network drive so it'll have to keep scanning the share. This may become a performance problem with larger secret shares. It would be better to run it on the machine with the physical disks.

This highlights a need for the Windows SyncApp to be able to install itself as a service so it can continue running after the user logs out ... but later.

[.SyncIgnore is great but...]

Whoa, please DONT sync the ignore file. In this case "ignore" has two meanings.

1) Pretend I don't have the file because it's local only; eg a temp file or an object (ignore "*~", "*.bak", "*.o" )

2) Pretend I do have the file because I don't want it; eg it's too big or just boring (ignore *.iso, *.bak, *.sh)

The first one needs the local files to be completely untouched.

The second one needs the ignore files to be independent.

Perhaps it'd be better to think of this as a sort of redirect; instead of being stored on the disk the file is stored in a black box somewhere. Say a fake disk with no free space.

PS: The swams are likely to be small, If I have a cloud node with only a little bit of disk space that's ignoring most (all) files will it be able to act as a relay for those files ? Should it be able to act as a relay or would it be sufficient to use say the Teredo relays ?

[Secret displayed on web gui]

I realize I can lock down the web gui, but it would be nice if there was a way to 'delete' the key from being shown ever again once the pairing was created.

The key is a shared secret for your secret share, it cannot be 'deleted' as such.

You can disabled the web gui altogether; this is by far the best for a 'safe' installation.

But ...

hey KOS!

Allowing the web gui to ONLY show the first page (without buttons) as a sort of 'public status' page sounds nice.

[A thought it was secure ?]

"Marko",

I've read what's been said as meaning that the limit on the amount of text that can be used to generate the key has been removed; this is good because it will increase the amount of entropy that people put into the key, making it "more random".

But very few cyphers can actually take an "unlimited" key unmodified, Blowfish is the only one I know offhand that has a very high limit (448 characters IIRC), for all the others you have to preprocess the key to "distil the entropy". The normal way to do this is to take a cryptographical hash of the entered keytext to generate the real key of 128, 160 or 256 bits. (NB: Many people forget to add salt to defeat standard rainbow tables at this point)

Based on what has been said and the size of the "info hash" that would be generated for DHT I expect the size of this distilled key is "only" 128 bits.

A "birthday attack" needs a parallel matching of all keys previously generated against the new key. This is a natural feature of the DHT network, it will, it must, automatically match a value derived from your secret against the same value from every other secret in use. So a matcher for the birthday attack is being handed to the attacker. I don't think that there will be enough keys in the DHT network to make it worthwhile, but someone else might have a better idea and this might give them a reason to make what looks like an attack against the DHT network.

OTOH: If the key distilled and used for the encryption is significantly larger than the 128bit 'info hash' the hash will not be unique enough for the for the DHT match to give you anything useful about a secret key match and there wouldn't be any reason to attack the network.

For this reason I hope the extended key is distilled into a 256bit key which is then hashed (with a constant string) to generate the 128bit "info hash". Then you don't have the one to one (approx) mapping between the "info hash" and the secret for the secret share.

Of course, as Peter said, this assumes the password isn't the weakest link. A cheap, multi card, GPU cracker (if one can be used) can test a billion keys per second, any six character password is insignificant against this level of attack. In addition the natural "birthday attack" of the DHT network means that the chance is about 1 in 300000 that two groups will accidentally get the same random 6 character password. This can easily get reduced by some sort of population stereotype. If the GPU cracker cannot be used a special rainbow table linking the (public) "info hash" back to it's secret would be workable for a password this short even with the 256bit intermediate keys.

You do need a much larger password, but you don't have to go overboard; a random password like "correct.horse.battery.staple" is probably sufficient. Though I might double it up until I'm certain that the network can't be used for a malicious birthday attack.

Peter,

But, as you say this is all conjecture, until it's been peer reviewed, you're probably best assuming that ROT26 has been used for something important

[A thought it was secure ?]

Having said all that, he may actually have raised a point.

It looks to me that this secret is being used in a manner that makes it susceptible to birthday attacks (ie there isn't a "user name" ) a birthday attack halves the number of bits in the probability of a collision so this may be susceptible to an attack of the order of 2⁶⁴.

While this is likely to still be enough, some cryptologists would disagree. This is the reason that SHA uses 160 or even 256 bits for it's hash generation.

[A thought it was secure ?]

>> Chances are slim but they do exist right?

I'll try this.

If I'm talking to a non-technical person the answer is NO; you would say that there's NO chance of it happening.

For example, lets assume that the chance of it happening is a billion to one, literally make 1000000000 attempts and one of them would succeed. Now this is actually a common lay person's shorthand for not just "impossible" but "so impossible I don't want to talk about it". The problem is it's not really impossible, in mathematically terms it actually just "quite unlikely". You see if there were really one chance in a billion that (say) somebody is born with stripes there would actually be six or seven stripped people in the world.

>> It will take decades for a super computer to guess that specific secret

The numbers here are far larger than that one of them is:

three hundred fourty undecillion two hundred eighty two decillion three hundred sixty six nonillion nine hundred twenty octillion nine hundred thirty eight septillion four hundred sixty three sextillion four hundred sixty three quintillion three hundred seventy four quadrillion six hundred seven trillion four hundred thirty one billion seven hundred sixty eight million two hundred eleven thousand four hundred fifty six.

The this is the sort of number that cryptologists think of as like "impossible". It wouldn't just take mere decades for some existing supercomputer to break it. The idea is like "NO supercomputer will break this within the next billion years" and the numbers are big enough that even if aliens arrive with some wonderful new tricks the lay person's answer will still be; "it'll never happen".

To get some idea of the sizes of the numbers involved you might have a look at the problem of "The second half of the Chessboard" .

https://en.wikipedia.org/wiki/Wheat_and_chessboard_problem#Second_half_of_the_chessboard

Then scare yourself with the realisation that we're talking about the third and fourth "halves" of the chessboard ...

[A thought it was secure ?]

Hmm, okay. Thank you.

But, I suspect I'd use a PGP mode to send the real key.

[A thought it was secure ?]

"one time passwords to safely pass secret over insecure media."

Could you explain this a bit, I mean I understand the "secret" is used to generate the rendezvous key (ie "info hash" equivalent) so you have to know it to be able to find the peers. This kinda conflicts with having some other password.

Would it be like the SSL certificate signing process where the Alice sends out an encrypted request to "Trent" who signs it offline and returns the signed message to Alice. Alice unwraps it and is able to prove themselves to Bob or any other member of the "swarm" (connected to via publicly released "info hash") because the key is signed by Trent.

[Synchronization when the computer is off.]

I'd put a NO vote against this if I may, while the idea is interesting (ie: using a passive 'cloud' storage location as a sort of message store) it's almost certainly more reasonable to use the cloud storage as a traditional 'ftp mirror' style location.

Of course if it is done, it's just as reasonable to send the messages via email ...

[WiFi and/or LAN trouble when going mobile with a laptop?]

One test I'd do with your two laptops is to connect ONE of them by wire (with wireless turned off) to your router.

The problem is that current WiFi encryption forces the connection between the two laptops to go via the base station. With both laptops trying to fill the air and the base station trying to talk to both of them at the same time this can drop the available bandwith a long way.

By my calculation 54Mbit/s becomes 1.5MBytes/s or less if there's anyone else trying to use the same channel.

NB: Does the Uni network block UDP traffic ?

[A thought it was secure ?]

The secret is (obviously) a 128bit base64 code. As such is IS secure with an 'impossible' level chance of a collision as long as you don't treat it as a plain password.

So do this ...

$ echo -n This is a very long password just for you | md5sum

e9112e7f0c3401113bacfced199308a4 -

$

Then convert it to get this as your secret ... 6REufww0ARE7rPztGZMIpA==

I think you need to trim off the '=' characters.

The wishlist is for this conversion to be available as a 'secret_as_passphrase' item.