nonsa: Encrypted Communication via BTSync

[deadserious]

I'm working on a new platform for secure, private and un-snoopable communications via BTSync.

The platform definition will be open (CC Licensed) and I'm nearing completion of a reference client that implements the platform.

A very early overview of the platform can be found here: http://www.nonsa.pw/. It's written as though you were having to do each step by hand with BTSync, but the idea is that clients implementing the platform will do all of the hard stuff transparently behind the scenes.

I'm actively seeking feedback on this including any security vulnerability analysis that you might have and look forward to the discussion.

[laurens]

Interesting idea. Here's some feedback:

- Typo in 4.C: it says 'Add the account account to settings.json.data file following the specification' - I assume you mean invite account or something?

- I think the fact that you have to give writable access to a share (the invite folder) is a risk; as BTSync currently is, I don't think there's a way to stop it from being abused; what would stop an evil-doer from storing 100gig there? It could either be a ddos on diskspace or bandwidth.

- I understand that the problem of an evil person deleting files from there can to a certain extend be mitigated since BTSync has the option to store a number of deleted/changed files on the client, but I think that too has a limit; I could change a file a 100 times, and that would also cause the client to have a lot of space wasted, and depending on how BTSync deals with that (can't find it ATM), could potentially also overwrite any legitimate old copies, if it is limited to store only a certain number of old copies.

- In the current document, you don't mention how to generate/manage public & private keys.

[deadserious]

Interesting idea. Here's some feedback:

Thanks for the feedback.

- Typo in 4.C: it says 'Add the account account to settings.json.data file following the specification' - I assume you mean invite account or something?

Thanks, will fix.

- I think the fact that you have to give writable access to a share (the invite folder) is a risk; as BTSync currently is, I don't think there's a way to stop it from being abused; what would stop an evil-doer from storing 100gig there? It could either be a ddos on diskspace or bandwidth.

I have a request in for a feature that limits the size of files to be shared on a writable sync. It can be mitigated somewhat by clients automatically deleting files bigger than x or that don't fit the expected format. But yes, until filters on a sync are in place, there is a possibility for unexpected files to go through.

- I understand that the problem of an evil person deleting files from there can to a certain extend be mitigated since BTSync has the option to store a number of deleted/changed files on the client, but I think that too has a limit; I could change a file a 100 times, and that would also cause the client to have a lot of space wasted, and depending on how BTSync deals with that (can't find it ATM), could potentially also overwrite any legitimate old copies, if it is limited to store only a certain number of old copies.

The file hash and signature should eliminate the ability for anyone to change files in that folder in a malicious way (outside of a disk utilization attack of some sort) as clients only accept files that validate. Also the invite sending client can continue to validate former invites that have not yet been accepted and reissue if they have been tampered with.

- In the current document, you don't mention how to generate/manage public & private keys.

The document mentions ECCDSA, the specified curve and that the public key is stored in the settings.json.data file. It's also states that the private key management will be up to the client and should be encrypted locally. What else do you think should be defined?

[deadserious]

The document mentions ECCDSA, the specified curve and that the public key is stored in the settings.json.data file. It's also states that the private key management will be up to the client and should be encrypted locally. What else do you think should be defined?

For the reference client I'm implementing the asymetric key encryption using OpenSSL and will include a definition of the commands used.

[alecperkins]

The publicly writable folder is definitely a risk, but there’s no other way to have an external prompt to a conversation without using some additional means. I requested a write-only key as a feature, which with proper whitelisting and BT Sync-enforced size limits could be reasonably secure and allow for external initiation, but that’s at the mercy of the BT Sync developers. The initial key exchange is definitely the hardest part about using BT Sync for messaging.

Could you elaborate on the need for encryption on top of BT Sync’s already encrypted transmission? I opted for a plaintext protocol for simplicity. It has the benefit of always being forward and backward compatible, and not even needing a client really. You can read my thinking behind the purpose/process of Missive by adding this key: B2CNYVXULNUVYH42J5DN6YTHJT6ESXOR3. (I’ve had similar thoughts about doing multi-party messaging, which is inevitably messy.)

[deadserious]

FYI, The Spec has been updated this morning to address some concerns and smooth implementation issues.

The publicly writable folder is definitely a risk, but there’s no other way to have an external prompt to a conversation without using some additional means. I requested a write-only key as a feature, which with proper whitelisting and BT Sync-enforced size limits could be reasonably secure and allow for external initiation, but that’s at the mercy of the BT Sync developers. The initial key exchange is definitely the hardest part about using BT Sync for messaging.

I'd prefer to see filters coded and attached to sync ID's so that files only transfer if matching certain rules. But as is, the risk can be mitigated somewhat with smart clients that quickly delete files that don't validate and therefore not passing along the bad files. That doesn't stop validating files from going along, (though they are useless unless they are real message invites within the system) and doesn't stop an attacker from just deleting files as soon as they come in to disrupt the system.

Could you elaborate on the need for encryption on top of BT Sync’s already encrypted transmission?

I am basically trying to mimic an email-like experience (CC's forwards, multi-party messages, etc) while achieving the goals of secure, authenticated and un-snoopable. If the invites went out unencrypted, then the metadata of who was talking to who would be visiable to anyone who might want to see it. The conversation key is encrypted in the invite, so theoretically, the conversation files themselves could be plain text without being remotely snoopable (assuming BTSync's protocol is encrypts in transport). However that doesn't eliminate local snooping.

The encryption of the conversation file on disk also lends to obfuscating the conversation from someone who might one day get your hard drive and want access to your messages. In order to view any record of any conversation, including any metadata of that message, the snooper would also need the private keys of one side of the conversation, and per spec those are AES encrypted locally.

Also, plain text on it's own does not help with authentication. By having each message in a conversation signed, you have a guarantee of who you are talking with.

Hope that answers your question.

BTW, I hope to have an alpha of a reference client out next week.

[jtroth]

I like this idea. Few questions/clarifications.

Is this intended to hide "metadata"? Could an omniscient adversary determine which users are messaging each other? If nonsa is truly private, it would be substantially better than PGP and significantly more scalable than BitMessage (it might provide some strong defenses against spam as well). Is 'private metadata' a requirement with which you designed the platform?

If you're hashing the user id, any reason why you aren't also hashing the writeable invite key as well? When it's hashed, spammers can't just send messages to every account in the namespace file.....they need to know a specific destination account (just like email).

You mention using symmetric crypto with AES in the 'assumptions' section, but only refer to asymetric crypto in the rest of the document. Are you using PGP for all message communication? S/MIME?

Is there a mechanism for re-initiating a conversation? Say one party loses their conversation secrets; can the other party determine whether a new invitation needs to be sent? Perhaps the conversations should have short time limits.

In any event....I'd definitely like to play around with this. Shoot me an invite:

joe@nonsa.btcloudsync.com

Also, I saw that you changed from ECC to RSA; did you make the switch for ease of development? I recently worked with ECC and was surprised how hard it was to find good tools and documentation......hope it catches up soon.

[deadserious]

I like this idea. Few questions/clarifications.

Thanks

Is this intended to hide "metadata"? Could an omniscient adversary determine which users are messaging each other? If nonsa is truly private, it would be substantially better than PGP and significantly more scalable than BitMessage (it might provide some strong defenses against spam as well). Is 'private metadata' a requirement with which you designed the platform?

The intention is to hide the metadata as well. As currently designed, the only leaks I know of are:

1. The query to the DNS server for nonsa.domain.com to get the sync key for the settings.json file.
   
2. Any leaks in the bittorrent sync protocol.
   

If you figure out any other leakage, I do want to get it bottled up.

If you're hashing the user id, any reason why you aren't also hashing the writeable invite key as well? When it's hashed, spammers can't just send messages to every account in the namespace file.....they need to know a specific destination account (just like email).

The invite key needs to be known and is discovered via the settings.json file. Since you can't decrypt a hash, you can't hash the invite key without making it unknowable. The hash of the id however causes any messages a spammer might send from validating the signature unless they also know the real id. A spammer could guess at account names the same way they do with email today, but if so, the spammer himself is an authenticated entity and can easily be filtered out, locally banned or ignored.

You mention using symmetric crypto with AES in the 'assumptions' section, but only refer to asymetric crypto in the rest of the document. Are you using PGP for all message communication? S/MIME?

I need to make some clarifications there and it will soon be coming with the release of the functional reference client. The same principles are in play as used in PGP and S/MIME and based on the same standards. Each encrypted message is encrypted with AES using a SHA256 hash as a key and that key is encrypted with either an RSA public or private key (depending on the situation). It's the same idea as PGP or S/MIME.

Is there a mechanism for re-initiating a conversation? Say one party loses their conversation secrets; can the other party determine whether a new invitation needs to be sent? Perhaps the conversations should have short time limits.

My initial thought is that this would be up to a client's implementation and a standard does not need to be defined. But I'm open to be persuaded otherwise.

In any event....I'd definitely like to play around with this. Shoot me an invite:

joe@nonsa.btcloudsync.com

Will post a link to the client soon at http://nonsa.pw and will announce here when ready. No invite will be necessary since you can set it up on your own domains at no charge and with no server costs. I may be offering a nonsa.cc service for people who don't want to use their on own domains, but that comes after a functional prototype.

Also, I saw that you changed from ECC to RSA; did you make the switch for ease of development? I recently worked with ECC and was surprised how hard it was to find good tools and documentation......hope it catches up soon.

I wanted to go with ECC for the best shot at future-proofing the protocol, but found that I was locking the protocol into a specific library implementations of the crypto. Finding something that worked in standard libraries, across platforms and across languages was a bigger chore than I had intended. RSA is easy, well documented and well supported in OpenSSL (which obviously has wide platform and language support). Also, it's easy for other crypto libraries to derive key information in a compatible manner to OpenSSL resulting in high compatibility.

[deadserious]

. (removed duplicate post)

[jtroth]

If you figure out any other leakage, I do want to get it bottled up.

 

This runs on BitTorrent, so the tracker (or DHT) gives a list of every host sharing a given folder.  If you want to know which hosts are communicating with Alice, just ping the tracker with Alice's invite secret every second.  This gives a list of every host initiating a conversation with Alice; you can then do reverse lookups on these hosts to find the initiating accounts (reverse lookups might be tough if it's difficult to enumerate all nonsa namespaces).  Perhaps this is acceptable for your requirements.....I don't know your threat model.

 

The hash of the id however causes any messages a spammer might send from validating the signature unless they also know the real id.

 

Can you elaborate on how this works?  I don't really understand what the hashed ID is good for aside from a way to link a writeable invite key to an account.  After that, is it ever used again?

 

From the spec:

Bill creates an invite.json file announcing who the message is from and the BTSync key for the conversation and signing that data with Bill’s private key.

Bill compresses invite.json file to invite.gz and encrypts to invite.gz.enc using Ted’s public key as found in the newly synced settings.json file.

Bill hashes the contents of invite.gz and renames invite.gz.enc to {hash}.gz.enc and places it in Ted’s invite folder for syncing.

Ted receives a new {hash}.invite.gz.enc file in his invite sync folder.

Ted validates the hash,  decrypts, decompresses and validates the signature.

 

How does Ted validate the signature if he does not yet have Bill's public key?  Does he do the nonsa DNS lookup, sync the namespace file, and get Bill's pub key that way?

EDIT: Ummm....how do you quote text?

[deadserious]

 

This runs on BitTorrent, so the tracker (or DHT) gives a list of every host sharing a given folder.  If you want to know which hosts are communicating with Alice, just ping the tracker with Alice's invite secret every second.  This gives a list of every host initiating a conversation with Alice; you can then do reverse lookups on these hosts to find the initiating accounts (reverse lookups might be tough if it's difficult to enumerate all nonsa namespaces).  Perhaps this is acceptable for your requirements.....I don't know your threat model.

 

 

Unless I'm missing something, you would be able to see which IPs are synching the invite folders, but that is about it.  The internals of each invite, including the conversation keys are encrypted and known only to those who are communicating and therefore the folder of the conversation itself would be private to the parties involved in the conversation.

 

 Can you elaborate on how this works?  I don't really understand what the hashed ID is good for aside from a way to link a writeable invite key to an account.  After that, is it ever used again?

 

By hashing the ID, a spammer can't just get a copy of the settings.json file and get a list of all usernames for a domain.  They would need to know an ID, hash it themselves and compare to the file.  It's obfuscation if nothing else and would allow you to use pseudorandom account names that would be nearly unspammable.

 

 From the spec:

 

How does Ted validate the signature if he does not yet have Bill's public key?  Does he do the nonsa DNS lookup, sync the namespace file, and get Bill's pub key that way?

 

Ted downloads the settings.json file and goes through each account, hashing bill@domain.com with the salt and comparing to the account record. If it matches he knows to use that public key.  He cannot download the file to find that domain.com has an acocunt bill without first knowing to look for bill.

[deadserious]

It appears the forum software has changed and quoting has become much more difficult.

[deadserious]

Just a quick update.  I'm pretty much at a crossroads.  Either I continue the app by hacking at BTSync and it's dat files to do what I need, or I wait for the API, which the team says they are just now getting around to spec.  

 

I'm leaning toward the former but due to the time requirements, need to schedule accordingly.

[ctismer]

Do you think about stopping BTSync, modifying the .dat files and then starting, again?

That is pretty doable, but takes of course some time when restarting.

 

I played a bit with the torrent file structure, pretty easy to convert them into Python dicts

and writing them back out. (there are a couple python modules around of different quality).

 

Hacking at the binary is harder, and I'm a bit reluctant, because that would get me into

days of exploring and debugging...

 

Btw., on Linux without Gui support, there is a simple ascii interface to settings etc.

Unfortunately, the Mac version does not react to any CLI argument.

[ctismer]

Additional comment:

Besides the already mentioned long delay until a sync is started, here is another

observation that lets me regard this software release less than beta:

I used BTSync to copy a large folder (iPhoto lib) between two directly connected Mac machines.

Both could communicate via Ethernet or WLan.

You bet what BTSync did?

In fact, it used the Wlan at 4 MB speed.

When I switched the WLan off, it took a while, but in the end transfer restarted, with 120 MB speed.

As a conclusion while trying to stay polite, I get more and more the impression that this is

a more or less working prototype for wetting the potential customer's appetite, but with no intent to make this

a serious project that can stand OSS standards.

Besides this critics, BTSync works quite well for reduced expectations, and that ist my way to use it for now.

I am abstracting from BTSync and any API, but simply try what's possible if the only safe assumption is that some changes will show up after a certain delay.

With that approach, I can also model some simpler scenarios based upon rsync or unison.

The simplicity of installing BTSync is anyway wonderful, and therefore I'm going to use a shared folder to boot everything on top of it.

So, alhough disappointed in many aspects, it is still a very useful tool, even if it just acts as

the fallback or bootstrap for a mote specialized system.

Sent from my Ei4Steve

[jtroth]

@deadserious

What functionality do you need?  If you're looking to create/remove shared folders, the linux client exposes a REST api that can work in a pinch.

 

@ctismer

You're right.  The BT team is probably the best in the world at solving the NAT traversal problem, but it simply does not yet have the reliability of dropbox (and reliability is usually the most important factor in transferring high value data).  In my experience, LAN sync works well, and sync with publicly accessible nodes works well.....but when you have nodes behind several layers of NAT, QoS starts degrading quickly.  Such is the nature of p2p technology.

[ctismer]

@jthroth

About the linux client:

Yes this is very handy. Unfortunately only for Linux-ish devices.

Is there a way to run the linux client on Windows?

As always, after some promising start of a project, I finally have

to do everything on an old XP 32 SP3 install. BTSync works there too,

pretty good, but no way to retain the simplicity of Linux I fear.

[deadserious]

Do you think about stopping BTSync, modifying the .dat files and then starting, again?

That is pretty doable, but takes of course some time when restarting.

 

 

That is exactly what I'd have to do.  Not ideal, but doable.  Of course it would have to be rewritten again once the API is released.

[deadserious]

Yes this is very handy. Unfortunately only for Linux-ish devices.

Is there a way to run the linux client on Windows?

 

The only real feasible way to do this would be if BTSync was compiled for Cygwin.

[ctismer]

Hey friend,

 

does that make sense, after all?

 

BTSync is great at hopping through NAT problems. That is true, the rest is not really

what we want/are used to.

 

I am very likely to abandon this stuff, keep what I learned (quite a lot)

and starting over! Open-sourced (although not in the next 6 months, of course),

and with a fresh concept.

 

My idea is to re-invent BTSync in a fresh way, with no relationships to old "new"

concepts like what Bittorrent has been doing for 12+ years.

 

I think a new re-start is over-due. And with all the good things we got, it should

not be that an unbearable brick.

I once started a real brick (PyPy, if you know that), which was way too much in the end

and made me probably sick. But this project could be very affordable, also in the

sense of health.

 

What do you think?

 

cheerioh - chris