HN Explorer

Show HN: ccPing, a secure messenger (ccping.com)

11 points by dnqthao ↗ HN
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.

- Ephemeral Chat: your messages will be self-destructed after a few minutes.

25 comments

[ 4.9 ms ] story [ 130 ms ] thread
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?

ksdkkdddd
Whenever someone uses "security" lately I start reeling... "What do you even mean by security? Privacy? Transperancy? Anonymity? Accountability? Reliability? Physical safety? Harmful to bad people or helpful others, and how? What specific properties and, for that matter, from whom's perspective - your's or mine?"

The term "security" implies so many ideas and many of them contradict that today it seems used mostly to help people feel safe while they are being cheated...

To that end, I would posit that anything that runs on Windows should be considered backdoored anyways, so I can't imagine why I would trust it to help my own personal "security" (privacy, and physical safety).

[deleted]
(comment deleted)
[deleted]
(comment deleted)
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.

weland
"We're using PBE" is obviously not quite the kind of answer that was expected here. For all we know, you could be OR-ing the characters of the password and doing a rotX with the result. Hardly secure.
dnqthao
Not sure why i cannot reply to the comment below, so i reply it here. 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.
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.

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!)

bugmen0t
You can have closed-source or you can have secure. This is the former.
dallagi
I'd love to see a similar project developed by a foundation such as FSF, Mozilla or EFF
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...

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.