Trsst: a distributed secure blog platform for the open web


It's interesting, though it's still very open to snooping if that's what you want to avoid. Users' public keys will be very accessible (as they should be), but because encrypted messages to that person are sent out to anyone with that public key, investigators of all types can build up a list of all the people that person talks to, and how often - just not what they're saying. Which coincidentally is the same sort of information that PRISM and other anti-terrorist agencies collect, as I understand them.


Also, while at one level it's an extension to the RSS client side, using the existing RSS logo unmodified as your own logo seems rather unprofessional.
 
It's interesting, though it's still very open to snooping if that's what you want to avoid. Users' public keys will be very accessible (as they should be), but because encrypted messages to that person are sent out to anyone with that public key, investigators of all types can build up a list of all the people that person talks to, and how often - just not what they're saying. Which coincidentally is the same sort of information that PRISM and other anti-terrorist agencies collect, as I understand them.


Also, while at one level it's an extension to the RSS client side, using the existing RSS logo unmodified as your own logo seems rather unprofessional.
Thanks for the insight.

These are important concerns.

I think I'll reserve some time to see how they intend to exchange messages. Maybe TOR could be introduced in some part of the middle. I need to read more.
 
The white paper suggests you'll issue an HTTP request for an RSS-like object. The HTTP request will contain your public key - which could be encrypted using HTTPS and having it as a POST form parameter in the request body rather than a GET request in the URL (I think - never tested that), but that would be kind of pointless anyway, since to send you a direct message people need your public key anyway.


The RSS object returned will contain public messages, which are signed by the author, and private messages which are encrypted with your public key. Your client would use your private key to decrypt those messages. It's all the same as using GPG on emails to sign or encrypt.


The tricky bit is that the white paper suggests that the server will use your private key to only send you the private messages if you send it the right public key, so they're sort of secret unless you send it the right key which is pretty much public anyway. And, in my experience at least, when you get an encrypted message you can see which keys were used to encrypt it, even if you don't have one so you can decrypt it yourself. So anyone spying on the system could see which users private messages were sent to, even if they couldn't see the message.


I don't see any way around that. GPG encryption exposes the same information, although at least there it's more open since you're actually sending the encrypted email to those people.
 
The white paper suggests you'll issue an HTTP request for an RSS-like object. The HTTP request will contain your public key - which could be encrypted using HTTPS and having it as a POST form parameter in the request body rather than a GET request in the URL (I think - never tested that), but that would be kind of pointless anyway, since to send you a direct message people need your public key anyway.


The RSS object returned will contain public messages, which are signed by the author, and private messages which are encrypted with your public key. Your client would use your private key to decrypt those messages. It's all the same as using GPG on emails to sign or encrypt.


The tricky bit is that the white paper suggests that the server will use your private key to only send you the private messages if you send it the right public key, so they're sort of secret unless you send it the right key which is pretty much public anyway. And, in my experience at least, when you get an encrypted message you can see which keys were used to encrypt it, even if you don't have one so you can decrypt it yourself. So anyone spying on the system could see which users private messages were sent to, even if they couldn't see the message.


I don't see any way around that. GPG encryption exposes the same information, although at least there it's more open since you're actually sending the encrypted email to those people.
I see. The design prioritizes indexable and distributed content, but gives less effort to this concern. If I understood correctly, you can talk to groups and each group would have a different keypair, then (from the prism's point of view) it's like another person and the data wouldn't be very accurate. Anyway, it'd still be "viewable".

You looks to like criptography. Have you seen homomorphic encryption? It's kind of exciting and I've been imagining how could this be used to create new forms of distributed computing.
 
Yes, I don't disagree with it providing the functionality to sign messages to prevent tampering. It's distributed nature is an improvement on existing centralised blogging systems, but you shouldn't imagine that just because you go to facebook dot com or twitter dot com to read and post to those services that your computer is talking to a single machine in california. With this you still need to register your public key with the core trsst network in America, unless you're running an independent trrst network, but at least if you go via a syndicating server, all those registration messages will come via that server and shouldn't contain identifiable information if done right.


The group stuff is interesting though, and you're right to point to that. It would appear, from a fairly quick reading of the white paper that groups stuff is based on symmetrical encryption, as it refers to group messages both being encrypted and decrypted with a public key (unless that's a typo - bit weird to refer to symmetrical keys as being either public or private). I guess that's a reasonable way to do it - since you're distributing keys over a private message anyway. Slight flaw in that to remove someone from a group you effectively create a new group not containing them - so it's likely the administrator who did that will send out n-1 private messages to the group in quick succession, which, if they're being monitored will reveal everyone remaining in the group. But otherwise it should be fairly resistant to sniffing over the air.


Thanks for the pointer to homomorphic encryption. Sounds like a tech you have to be very careful with (and it was news to me the ElGamal encryption was partially homomorphic as is), but it's an interesting development in being able to work with a message keeping it encrypted end-to-end, and you're right, in distributed computing it should enable more efficient operations on encrypted data. I don't pretend to understand any of the maths behind this stuff though - I stopped at 'multiply two big prime numbers', but I find it's applications to be interesting.
 
Its cool, but why should I give them money? This should be "buy me a beer after you use it for a while an realize how great it is" not "give me money so I dont have to keep working my shitty trash collecting job"
 
I've no objection to paying for open source software.  Someone has to pay for it - most open source devs have day jobs writing closed source code for da man, so at least this way it means there's a little more open source software and a little less closed stuff.
 
Cool, I see they've taken my criticism of their logo on board ;)


Shame the example link from the github faq doesn't seem to work. If I hit the back link from there it seems to get me to the same page with the same URL, but it works (guess that's a referrers thing then). The RSS feed loads of course, but it's full of junk as well as the intended content, and the images are broken. But hey, it's a beta of unproven technology, so I'll grant it some levity.
 
Back
Top