

Show HN: ccPing, a secure messenger - dnqthao
http://ccping.com
With the 2 prominent features:
- Encrypted Chat: your chat will be encrypted with a password so only when you type in the correct password then it will be unlocked.<p>- Ephemeral Chat: your messages will be self-destructed after a few minutes.
======
KMag
99% of people don't know that they don't know enough to know this is providing
a false sense of security. People running illegal underground charities in
West Whereisitstan are almost certainly not crypto experts, and are all
probably fairly naive in the way one has to be naive in order to do charity
work in West Whereisitstan. "Caveat emptor" doesn't cut it.

Single DES is absurd in this day and age, and password-based encryption is
worse. Jack the Ripper renders this no stronger than a secret decoder ring,
and a thousand times more dangerous because of the false sense of security.

Edit: I'm probably overly sensitive. One of my ex girlfriends has several
uncles, three of whom went to prison for not belonging to the state religion.
Thankfully they didn't live in one of the countries where such things are
currently capital offenses, and were able to immigrate to more tolerant
countries.

Perfect forward secrecy needs to be the default, perhaps with an option to
switch to a stored history mode. Use 256-bit AES in GCM mode.

For the stored mode, don't use password-based-encryption, but rather generate
a GnuPG key pair on each device the first time the client is used. 4096-bit
RSA/El Gamal or 256-bit ECC should be the minimum key sizes. The first time a
new device is added to an account, upload its public key and tell the user
they need to "authorize" this device from one of their existing devices in
order to see past conversations. When they log in from another device, ask
them if they've really added the new device, and if they respond that they
have, have the old device add the new device as a recipient to all of the
existing messages. This can be done by sending only the preamble of each
message to the old client for it to decrypt the symmetric key, and re-encrypt
the session key for the new recipient, and send the encrypted session key back
to the server. Don't take any shortcuts. If a conversation is between Alice
and Bob, and Alice adds a new device, never ask Bob to re-encrypt old
conversations for Alice's new device, because Bob's answer will always be
"Mein StasiPhone? I dunno if Alice added a new device. Fuck it, sure, why
wouldn't I give Alice's new phone access?"

If your product as currently implemented gets many users, it's a statistical
certainty that some of them will go to prison due to the false sense of
security you're giving them. I hope they're all going to nice prisons in
respectable countries and for doing things that are objectively evil.

~~~
KMag
Oh, and the right way for Alice and Bob to prove to each other that the
holders of their public keys both know the secret password is to use an
Augmented PAKE [1] (Password Authenticated Key Exchange) protocol, replacing
the password with Scrypt( Concatenate(Alice's public key, Bob's public key),
Password ). (The concatenation of the public keys is used for the Scrypt
salt.) That way, at the successful conclusion of the Augmented PAKE exchange,
Alice and Bob haven't proved to each other knowledge of the password, but
rather have tied the proof to their two public keys, and each can be assured
that the holder of the other public key knows the password. If there's later a
flaw found in the Augmented PAKE algorithm you choose that leaks the
"password" used for the Augmented PAKE protocol, at least you've only leaked a
memory-hard password hash of the real Password.

[1] [http://en.wikipedia.org/wiki/Password-
authenticated_key_agre...](http://en.wikipedia.org/wiki/Password-
authenticated_key_agreement)

Don't get creative and start rolling your own zero-knowledge proof of
passwords here. It's really easy to get wrong. Use a very-well peer-reviewed
Augmented PAKE algorithm.

THE NAIVE WRONG WAY for Alice to prove to Bob that she knows the Password (but
might look good at first glance) is for Alice to send to Bob HMAC(Password,
Alice's Public Key) because then if Bob doesn't know Password, he can still
start bruit-forcing guesses without further interaction with Alice. On
average, it will take the Stasi an afternoon to bruit-force Password after
pretending once to be Bob, and after that they can impersonate Alice when
talking to Bob. It's very unlikely Alice will ever mention to Bob the one
failed authentication, and nearly impossible that she'll mention it within the
window of time they have before the Stasi bruit-force the password.

Use an Augmented PAKE instead of a balanced PAKE, because you should use an
Augmented PAKE for users to authenticate themselves to you, and that way you
can share one implementation for both purposes and expose yourself to half the
potential bugs. With a Balanced PAKE, if an attacker gets read-only access to
your server's password store, they could immediately authenticate themselves
to your service and upload more public keys as the user. An Augmented PAKE in
this case would slow down an attacker by forcing the attacker to bruit-force
the passwords, and would completely save the 1% of your users who use
passwords with 80 or more bits of entropy.

------
gnur
Interesting, but without any technical details I'm not going to use it.

There isn't even any mention of it being encrypted.

------
altandotme
A highly detailed explanation on how encryption is used and what type etc, is
most definitely needed on the products website to make anyone vaguely trust
this.

IMO, the app interface needs improving.

------
richo
"secure"

I weep for all the claims this makes about security.

~~~
dnqthao
Maybe you can elaborate more on this.

~~~
cwoac
Okay, what form and key size of encryption is in use? What implementation is
it? Does it do PFS? is it salted? Where/for how long/how are messages stored?
Who has access to the encrypted form of the messages? What block mode is being
used here? How are you handling the iv initialisation? Per message? per
person? per conversation? What are you using to determine the IV value?

~~~
dnqthao
The encryption use is PKCS #5 (5.3 PBE with MD5 and DES). The algorithms are
outdated but in the subsequent release we can update it to SHA-2 and AES-256.

We cannot do PFS because we have the feature that a person can login to
different devices and can still see the same messages and continue the chat (
given that he knows the chat password)

~~~
richo
This alone should have blocked your launch. Crypto done right is innately
pluggable, by virtue of being composable primitives.

Between this and your "but we totes destroy ciphertext after T seconds" (which
is just flat out untennable, and unprovable) I'm pretty spectacularly weary.

I'm also pretty curious to know how you're deriving keys from the users
passwords. How is the exchange of key material handled?

------
bugmen0t
You can have closed-source or you can have secure. This is the former.

------
reganrob
"ONLY you and your partners, who know the password, can access the secure
messages"

Maybe I missed something, but how exactly is this "secure"? I'm assuming
ccPing will still store these messages in a database which will be vulnerable
to attack.

I mean, is this going through the TOR network or something?

~~~
dnqthao
The message will be encrypted on the client side (iphone , android or PC ) ,
so the message sent over the network are already encrypted using the password
provided by the user. So only when the user type in the correct password then
he can decrypted it. If he forgot the password , so sad, the message cannot be
read anymore.

~~~
reganrob
Could you go into more technical detail? How are the messages encrypted? I
mean, is it subject to a brute force?

~~~
cwoac
Given way the password is distributed, I doubt the encryption is salted.

------
pubby
What type of encryption is this using?

~~~
gnur
I believe there isn't any, the word encryption isn't even on the website.

~~~
dnqthao
We are using PBE for the messages in the secure chat ( you can choose whether
to start a normal chat or a secure one ).

The encryption is done on the client side, so the message going through the
network ,storing on the server are all encrypted. Only when you type the
correct password then you can decrypt the message.

~~~
dnqthao
An example:
[https://www.facebook.com/photo.php?fbid=263620283790579&set=...](https://www.facebook.com/photo.php?fbid=263620283790579&set=a.263620280457246.1073741829.263590463793561&type=1&theater)

------
dallagi
Yet another closed-source "secure" messenger. That's interesting, but if I was
a chinese dissident I would never trust a closed-source messenger.

(btw I would try it for sure if you'll port it to BB10!)

------
dallagi
I'd love to see a similar project developed by a foundation such as FSF,
Mozilla or EFF

