deadserious

Members
  • Content Count

    28
  • Joined

  • Last visited

  • Days Won

    1

1 Follower

About deadserious

  • Rank
    Member
  1. The only real feasible way to do this would be if BTSync was compiled for Cygwin.
  2. 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.
  3. 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.
  4. I have been SHA512 hashing a passphrase and then base64 encoding. It seems to work fine. I just wish I knew how to generate the Read Only key for it too.
  5. Would love an update on the timeframe if you have one.
  6. It appears the forum software has changed and quoting has become much more difficult.
  7. 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. 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. 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.
  8. Thanks The intention is to hide the metadata as well. As currently designed, the only leaks I know of are: The query to the DNS server for nonsa.domain.com to get the sync key for the settings.json file. Any leaks in the bittorrent sync protocol. If you figure out any other leakage, I do want to get it bottled up. 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. 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. 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. 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. 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.
  9. FYI, The Spec has been updated this morning to address some concerns and smooth implementation issues. 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. 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.
  10. For the reference client I'm implementing the asymetric key encryption using OpenSSL and will include a definition of the commands used.
  11. Your suggestion would be sending unencrypted files through the sync process rather than the entirety of the encrypted volume. Should sync become compromised in some way, the attacker would be getting the unencrypted data that you worked to protect with TrueCrypt..
  12. That would completely defeat the point of using TrueCrypt.