Talk:Encryption

Contents

[edit]

certification authorities do not work

At least that's what heldensaga experienced:

cacert and startcom give you host-certs based on that you receive an email at something like postmaster@host for example so they are vulnerable to dns-spoofing and tcp-hijacking, at least i once bought a cert from thawte (a verisign company...), they hadn't much more visible security, too. at least they had a credit card number and probably did some checks on that, but i can't know. however, that's not what i consider very much secure ... self-signed certs may work for client2server communication but not for server2server communication. somebody has to check the fingerprints etc a "circuit" between two psyc servers is very much detached from the users of the server so you don't even really notice it and can't check for the cert or fingerprint or anything. well, of course, it is theoretically possible to add commands to psyced allowing access to that, but i think that's not really practicable.

In fact CA-based TLS is even less trustworthy than that. See main article.

[edit]

Using TLS in a less certified way

It's not as good as being off-the-record, but at least being less certified can provide some useful features.

  • A self-signed certificate is certainly less certified, let's see it intentionally as not proving anybody to be anybody, but it proves it's the same person (or server) as last week.
<fippo> it does not prove that. TLS only proves that you're talking to something that uses the same public key as the thing you were talking to last leek.
Well.. if it understands the messages I am sending it to, then it also has the same private key as the one last week, that's what I mean and that's what I expect from it. Given I also check fingerprints or use some socialist millionaire protocol thing, I gain safety from MitM attacks.
  • A self-signed certificate cannot be renewed in a trustworthy way by any CA as a self-signed has none by definition. What we can do is pick one of the two variants following:
[edit]

Variant 1: Reject expiration

Reject the concept of expiry embedded into X.509 and use self-signed certificates forever.

<fippo> which means that if your key is compromised you don't have ANY chance to recover. Never ever. There is a reason why x509 certificates have a concept of expiry.
Of course you can't recover. You lose the private key and your stuff can be decrypted forever (unless you have been using DHE safely). Expiry doesn't help you for nothing, it only is intended to stop your communication partners to keep on sending you stuff using a corrupt key. That of course will no longer work, but we have other ways to inform our communication partners in PSYC. We are not depending on certificates getting revoked or expiring. In a world of friendcasting they are old-fashioned and pointless.
[edit]

Variant 2: Self-renewal

Sign your new certificate using your previous certificate.

<fippo> afaik not possible.
Officially not, maybe. But I am talking about perverting the commercial TLS scheme to a more rebellious use, this would allow to do so. I don't see how the technology can keep me from doing this.
Show me your new self-signed certificate signed by your old expired self-signed certificate please.
Why expired? You are confusing Variant 1 with Variant 2. Let's talk about variant 2 here: I put my new certificate into a message, wrapped in a suitable PSYC packet, then encrypt the entire thing using my soon expiring private key and friendcast it. So I'm not really signing it, I'm simply the only possible source for it. Maybe I could as well sign it, but since identification is not the point in this whole plan, I shouldn't have to. Next I can throw away my old private key and retro-actively improve my security - should I ever have needed to communicate without forward secrecy handshakes (like for recorded messages for offline recipients).
[edit]

PROs and CONs

In both cases you MUST never lose your private key, or you lose your virtual identity with it! But that goes for pretty much any strategy unless you surrender to an external authority. But we don't want those, as we don't trust any (see saga's experience above).

PROs:

  • SS-TLS can interoperate with regular certified TLS. Everyone can decide whether he wants to be fully liable for the things he does on PSYC, or not.
<fippo> no one from "certified TLS" will trust you. Interoperability is only with people who are using TLS like XMPP admins do.
Of course, unless we are talking about PSYC and we are the ones dictating the rules here. In our world we can distinguish certified from intentionally less certified sources. Both have a right to exist. So in PSYC people would by default not be certified, and if someone doesn't like that, he can limit his PSYC usage to the subset of certified ones.
regular certified TLS' won't interoperate with you. The 'interoperation' is one-sided from your side only (and no, you may not claim yourself to be 'backward-compatible', as your approach is not superior).
That is incorrect, it's just a political assumption of yours what certified administrators would do. If I am the writer of the code of the certified PSYC server I can teach it to accept all certificates, then let the users decide which ones to trust. See below in Crypto services with TLS.
you're muddling the distinction between authentication and identification. You're attributing identification to TLS whereas this is really a feature of x509.
I am using TLS and X.509 certificates for authentication purposes and not identification purposes. Which parts of the plan belong to which technology I find quite secondary. Why do you discuss it instead of fixing the wording if anything is ambiguous? This is not how a wiki is intended to be used.
We're in Talk: which is intended for discussion.
In fact I consider a certificate which is only backed by a public CA a lot less trustworthy than a certificate whose fingerprints I have checked in person, or a friend of mine did. So you may find me treating CA-TLS only little trustworthier than plain unencrypted TCP. Of course we could make the judgement a per-admin or per-user choice, but how much education on privacy does it take for them to take the right decision? Do they know enough about the current state of unsafety in CA-based TLS?

CONs:

  • It still doesn't operate end-to-end, but that's not the point here. We want both link-level encryption and end-to-end encryption.(well, heldensaga suggests an alternative to link-level encryption, see below)
  • To make it transparent, that a path from one end to the other is entirely handled by either TLS or SS-TLS, we MUST send _warnings whenever encryption is missing or untrustworthy.
  • We must enforce Diffie-Helman handshakes so that, should your private TLS key get compromised, your communications aren't all retroactively decryptable.

By the way, Wikipedia:Self-signed_certificate claims that they only work for small groups, but who said we want to certify each other in the first place? A certificate only certifies itself. Then we can use fingerprints to make it less probable, that someone is an impostor - but if we met online anyway, we don't even need that. Our first meeting defines our identity.

<fippo> Finger prints are made for humans. Machines can, should and must use the full certificate.
Did I mention this is rebellious use of TLS and X.509 technology? Anyway, I did mean human use of fingerprints, not automatic. But some people might prefer to do it automatically, who knows? Can you hate them for that? Is it worse than the current practices of broken certificates or no encryption at all?
[edit]

Real OTR circuits

lymeca suggests that having real OTR over PSYC interserver links, that is apply the OTR signing thing on a per-server basis, not on a per-identity basis, brings advantages compared to a poor TLS-based solution:

Former PROs:

  • OTR provides perfect forward secrecy: each message is encrypted using a temporary AES key, so if any long-term keys are compromised, old conversations are inaccessible.
<lynX> TLS should be able to use EDH ciphers, too - if we get that to work, it provides PFS too.
  • The lack of digital signatures provides deniable encryption, what you say cannot be used in trial against you.
<fippo> OTR doesn't lack digital signatures (slide 17 of the 2004 presentation). OTR provides repudiation ("Anyone who can verify can also forge").
Yes it does, the MACs used by the two sides only ensure, that one of them wrote the message, which only proves to the first one, that the other one wrote it. The author of the slides laxly called them signatures in his presentation apparently, but the real paper is pretty clear about this. We are however only talking about vocabulary, which doesn't take away from the actual information, like... In a multi-peer situation anyone involved could have written the message. No matter how you put it, what you say cannot be used in trial against you, unless the person you are talking to is the trial or something like that - hehe ;))
<lynX> Using SS-TLS with EDH should be equivalent, if I got it right.

PROs:

  • Since SSH is a safe protocol, too, should a user decide to trust his own server machine, he could find it practical to have a PSYC router that can itself handle all OTR to all his friends. The advantage of using interserver OTR would thus be, that we use the same technology for both purposes.

CONs:

  • This of course requires libotr to be linked into psyclpc etc, whereas TLS is close to ubiquitious in today's server technologies. (We could link the entire libpurple into psyclpc and learn all centralistic transport protocols this way.. hahaha)
  • Since we are likely to also want to support XMPP in the future, this doesn't let us get rid of TLS.
[edit]

Crypto services

heldensaga suggests having psyc://example.org/$crypto services which take care of routing your encrypted message to your final destination. Works like this:

  • You encrypt your end-to-end message to the final recipient.
  • You send it to your $crypto service.
  • It creates an encrypted header containing actual sender and recipient of the message.
  • It sends the entire package to the recipient's $crypto service which unpacks the header and forwards the encrypted message to final destination.

PROs:

  • This strategy works essentially in the same way as the end-to-end strategy, so it is a cleaner approach from a protocol design point of view. It works like an optional add-on.
  • No re-encrypting of already encrypted data.
  • No encryption of data that we do not care to be encrypted, like file transfers in some cases.

CONs:

  • Multiple encryption operations on headers are more complicated than just applying encryption to the entire circuit.
Why multiple? saga 10:45, 7 August 2007 (CEST)
<lynX> for each packet rather than in a continuous stream that TLS libs take care of ...
  • We're inventing our own cryptography strategy and have to implement the whole thing by hand.
  • We still need to authenticate hosts anyway (but DNS may be sufficient, as we already do)

And we have no data on processing efficiency: Is repeatedly generating encrypted headers cheaper processing-wise than just throwing everything into one big encrypted stream?

P.S. I'd like to add that a $crypto service object isn't strictly necessary. It is an architectural decision whether such a tool has its own address or is essential enough to be provided by the server root.

[edit]

Certification beyond the authorities

Ensuring a server is the same as last week's, without just simply trusting X.509 validity of certificates, means keeping a collection of server certificates and making trust checks yourself. This hasn't been implemented.

Certificate checking isn't automized either - we'd have to come up with a plan. Here are some options:

  • Enforce manual socmill or fingerprint checking. You can't talk to a server until your admin has ensured that server is who he claims he is.
  • Wait a minute.. isn't that what we wanted to avoid? Well, we can avoid it, but then we have to accept that there is a man-in-the-middle vulnerability at the moment of first contact. Ouch...
  • We could come up with a strategy of friendcasting certificates in advance.
  • We could accept the combination of friendcasting certificates plus CA signing as an acceptable level of safety for first contact.
  • We could pass certificates through to the client and let the user decide whether she trusts them for her communications.
[edit]

Obsolete: Presenting interserver certificates to end users

$crypto services may present certificates of other encryption services on the route to the client, which might let its user decide, inform the service - which might then send the users messages over those crypto services or not, depending on the users decision. Implementing that circuit-based would impose quite some problems, mainly:

  • The circuits don't have an address they can use to communicate with the client/user.
  • The circuit's job is to deliver data. Once a message reaches the circuit (internally), there is nothing to decide anymore, the message should be sent. This would have to be done on a higher level, which in psyced currently is: sendmsg(). However, sendmsg() has an even sadlier perspective when it comes to being accessible through an UNL...

Depending on how we do it we could implement a $crypto service which is entirely stateless and leaves all certificate knowledge on the client side. I have a feeling however it is more useful if the $crypto can verify certificates and the client is merely informed and given choices (like checking fingerprints interactively). This opens up the possibility to say Your friend Jack has already seen this certificate and considered it valid.

Nice idea, but the user can't be sure we are really using the cert we are showing (that her server is doing the right thing). So this is all no replacement for real end-to-end cryptography, and it is overkill for mere transport layer encryption.

[edit]

Crypto services, presenting certificates, with TLS

Although I like the per-packet-based $crypto I'd like to mention for completeness that a certificate manager tool may also be applied to TLS circuits. In that case the server would generally accept TLS connections but let the $crypto service negotiate with the end user whether she finds this or that host's TLS certificate trustworthy enough for her purposes. $crypto would not need to do any routing itself, but it would monitor all packets going in and out of circuits on behalf of its users.

<fippo> essentially this is the browser way where the human decides. I like that approach.
Not exactly, because the human gets to decide over interserver certificates, which is a lot crazier and totally new territory. This does however imply re-encryption of already encrypted data, which is uncool.
[edit]

The crypto service and friendcasting

Once you have acknowledged you trust a server, you may want to let your social network know, so they have some hints who to trust. Trust could even be adopted automatically, or depending on trust maths. Same goes for blocking (negative trust), see also SPAM. This is taking activity streams way beyond sharing some video clips.

[edit]

TLS with announced renewal

Having channels to announce certificate renewals seems to be a necessary step. You MUST NOT accept a sudden change in certificates if the involved node didn't serve up a signed announcement, that such a change is imminent, and without delivering a self-signed copy of the certificate ahead of deployment. This is independent of the certificate also being signed by a traditional CA, allowing for multiprotocol usage (Would however be better to upgrade the trust logic of those protocols, too).

Such a certificate subscription and multicasting technology would protect against CA-based MitM attacks. What remains to be solved is how to deal with a new node, how to make friendship on an interserver level.

  • Manually, one by one, checking fingerprints or using a socialist millionaire approach.
  • Using the web of trust, let trustworthy servers friendcast certificates to you.
  • Fall back to the traditional CAs, believe them just once at the beginning. Mitm attacks from CAs are dangerous because they can be deployed anytime when needed. Using this strategy, they could only be effective if introduced from the very beginning. This is unlikely to happen on a global scale as the owner of the certificate himself is likely to notice the trick, but a specific target could still be attacked by Mitm on all new acquaintances. So it's up to you to accept CA-based trust at the start or avoid it altogether.
[edit]

Definition: paranoid TLS aka pTLS

  • All hosts that are mentioned in _source, _target or _context variables MUST have been defined in respectively the sender's or the recipient's certificate. Any breach is treated as an _error and reported. No other in-protocol host authentication is to take place (not even, as currently, by DNS).
  • Enforce EDH for forward secrecy. Communications are dropped if PFS cannot be established.
  • Certificates do not expire according to X.509. That behaviour SHOULD be overridden (See Reject expiration). You are encouraged to generate long-lived certificates, in case overriding such a behaviour is technically non-trivial.
  • Certificates can only be renewed by a multicast from the owner of the certificate, carrying the new certificate super-signed by the old certificate (See announced renewal or, if you really don't like CAs, Self-renewal).
  • The new certificate should however also be signed by a certification authority. Since CAs are not so powerful in pTLS, it is okay to add alternative CAs and CAs of your friends.
  • If a new host's certificate hasn't already been friendcast to you, store it for manual inspection, no matter how expensive the CA that signed it, and deny communication. Only a manually checked certificate is good for you and your friends.
  • When you check a certificate manually, send out a friendcast to your friends' servers according to a protocol that we have to figure out as yet.

PROs

  • It is so easy to implement (having PSYC for the friendcasting ;))
  • It's much better than any existing TLS scheme
  • It's already better even if we don't have the friendcasting bit yet - simply the fact of not accepting randomly signed or unsigned certificates.

CONs

  • crypto-services and OTR circuits may be good or better options, even if they are more work!
  • This is still just a link-layer encryption plan and no replacement for end-to-end encryption using OTR or similar technologies.
[edit]

Definition: responsible TLS aka rTLS

  • All hosts that are mentioned in _source, _target or _context variables MUST have been defined in respectively the sender's or the recipient's certificate. Any breach is treated as an _error that leads to a destruction of the circuit and gets reported. No other in-protocol host authentication is to take place (not even, as currently, by DNS).
  • Enforce EDH for forward secrecy. Communications are dropped if PFS cannot be established.
  • When encountering a untrusted certificate, store it for manual inspection. Let the responsible admin decide about trust.
[edit]

prTLS in immediate mode

Instead of doing a negotiation in the circuit we get started quicker by deploying immediate prTLS on port 9404. That's a variant of PSYC where TLS is started immediately and PSYC protocol only happens within the TLS stream. No negotiation.

And prTLS is something inbetween pTLS and rTLS... at admin's tuning discretion..  ;D

funny-pictures-sideways-smiling-cat.jpg

[edit]

Special applications

[edit]

psyconaut

Because there is no OTR library for .net available, my psyconaut will integrate a diffie-hellman key exchange to share the same key securely, and a aes256 encryption for the text.

[edit]

/key exchange

alice thinks it would be nice to have this psyced internal.

to split it up a bit:

  • command for key-exchange between two psyced entities

that would generate prime and prime root for dh and could contain a list of supported encryption methods and send them to the target. the target sends something similar back and they have a key for encrypting their messages. a room could request this from a person on enter or persons from each other before message start. Funny thing is the room could actually do a mitm attack and multicast this to a channel while persons joining the room without key exchange have no way of reading what is going.

  • then client or later sending messages could check for an existing key between source and target.
  • would leave certified trust and hiding the route to servers or rooms

<lynX> Essentially you are suggesting libotr in psyced here, or something similar in a homebrew style. see above.


Credits:

This discussion and the idea of having interserver OTR was triggered by lymeca. saga has added the crypto services concept whereas I came up with SS-TLS and worked out many details. fippo has asked many tough questions helping solidify the concepts. Are you, the reader, going to contribute something more? Please do.

[edit]

Reliability and OTR

<lynX> After some years of intense OTRing I find it annoying how OTR itself does not provide much protection from breaking links - when you drop out of your wi-fi lan, your partner's client crashes or anything else like that. OTR doesn't provide the reliability that the other side actually received what you sent and that you received everything that was told you. In fact, why should it? XMPP, IRC and other protocols should provide this for themselves, but pretty much none of the messaging technologies do. It could be better with PSYC, since the simple echo feature already provides for reliability feedback - this however requires a native PSYC client to integrate OTR in a way that outgoing messages are not displayed just because they were typed but rather echoed on acknowledgment. This requires a change in the inner workings of OTR actually.. like putting the PSYC entity packet part into OTR in its entirety, making it incompatible with non-PSYC OTR clients. At this point we might as well use a native binary OTR/PSYC encoding, thus moving away from OTR as it is today. On the other hand, typed echo would be kind of okay if there was more aggressive error reporting - but currently purple/libotr doesn't even complain when the message didn't safely make it to the client's server, let alone ensuring interserver reliability. Maybe this should be addressed in libpurple really.

fippo informs, that if all involved clients and servers implemented XEP 0198 and in a way that users are helpfully informed of the situation, XMPP would provide the required reliability.
Retrieved from "http://about.psyc.eu/Talk:Encryption"