
Umbra Privacy Platform - agmontpetit
http://umbra.shadowproject.io/
======
tptacek
If this is their chat scheme:

[https://github.com/shadowproject/whitepapers/releases/downlo...](https://github.com/shadowproject/whitepapers/releases/download/1.0/ShadowChat.pdf)

... that's really scary (ECDH + ECDSA + CBC mode, using OpenSSL's primitives,
in an ad-hoc configuration, with plaintext compression), and also inferior to
modern secure messaging schemes. People should use Signal Protocol for this
stuff.

 _Slightly later_ :

The only source code I can find for this is a giant collection of C++. There's
CSS referring to "ShadowChat", and a file "smessage.cpp" which roughly
corresponds to the protocol sketched in that PDF. It's C++, lots of it, with a
lot of memcpy.

~~~
kewde
Hi,

If you want users to take your comments seriously then you should be a bit
more specific about what's scare. CBC and ECDH are the basis of most modern
end-to-end encrypted messaging schemes.

I agree with the key exchange, it doesn't have a proper ratchet, it's on our
to-do list.

~~~
tptacek
I'm really, really comfortable with who does and doesn't take my comments on
this particular subject seriously. If you rephrase your comment in the form of
a question, I'll respond.

~~~
kewde
Hi,

I didn't mean to come off as rude, it's a bit late and I'm quick to the
trigger sometimes.

What are your concerns with our scheme? Do you have any suggestions on
improving it?

We really need to implement a key ratchet, that's a sure thing.

~~~
tptacek
It's 2002-grade crypto primitives, hand-rolled, written in C++, apparently on
top of OpenSSL's primitives.

Nobody is going to be able to sanity check this code "in real time" in
response to message board comments. But I skimmed it, and I see concerns right
away. For instance, it looks like the CBC IV isn't included in the MAC
calculation.

In terms of primitive selections:

* CBC+HMAC is fine if you're very careful. I'd certainly do that before I tried to hand-code a real AEAD. But then, see above! A modern protocol would use either a hermetically sealed AEAD construction like GCM, or, even easier, use ChaPoly, as provided in TweetNacl.

* I can't tell what curve this is based on, but I'm guessing because this is all bitcoin related it's secp256k1. New protocols shouldn't use secp256k1, if only because it's not misuse-resistant. I'm assuming this project inherits its secp256k1 code from wherever bitcoin gets it, but anyone else who tried to interoperate with ShadowChat has to carefully avoid invalid curve attacks as well.

* ECDH is fine. Whatever. The problem is secp256k1, not ECDH.

* But ECDSA is not fine. It relies on a random nonce and explodes like a pipe bomb if so much as a single bit of the nonce is biased, which is surprisingly hard to get right. It's also difficult to make ECDSA constant time with arbitrary curves.

That's just the really basic stuff, though. Secure messaging systems are
surprisingly difficult to get right. You need to understand the underlying
crypto primitives very well, but then also a whole mess of almost- domain-
specific stuff about messaging protocols with particular threat models.

This is not a good thing to DIY.

 _Later_

And, I mean, I have structural concerns with this C++, too. For instance:
there's a place that passes an integer computation to std::vector's resize,
then memcpy's into it on the assumption that the computation didn't shrink the
vector. Is this a real problem? Fuck if I know. You know what it costs per day
to really audit C++ code like this?

 _Later Later_

Sorry, I forgot: compressing plaintext creates traffic-analytic side channels.
Back in 2002, people thought it was a good idea to compress plaintext, because
it destroyed structure and made some attacks harder. But then CRIME was
published and now we all worry about compression --- also, it turns out, the
code for the exploits compression was supposed to stop gets trickier, but not
impossible: see "Dancing On The Lip Of A Volcano" for more.

Also: how much of this code is your project's, and how much is inherited?

~~~
kewde
Hi tptacek,

We know that thorough review does not happen instantly. I want to let you know
that we have bounties and funds available for doing code review.
[https://shadowproject.io/en/bounties](https://shadowproject.io/en/bounties)

* That's indeed true, we will be including the IV in the HMAC. Will be patched in our next version. Thank you!

* ChaPoly by TweetNaCl - dearly noted. The thing is, libs need compatibility with our curve. TweetNaCl only supports Ed25519 :/

* secp256k1 is correct.

* Do you have any references to the "exploding like a pipe bomb" problem? We're using the ECDSA from the bitcoins secp256k1 library - which is constant time and should be secure enough. Function: RecoverCompact()

We initially paid for a cryptographic review but the guy, whom we know by real
name, disappeared from the planet. We're scouting for cryptographers willing
to do code reviews, for a payment ofcourse.

If you're capable and interested then you should reach out to us on GitHub or
Slack!

We do appreciate you doing this in your free time, so we're sending Bitcoin
tips to whoever makes good suggestions. Please post your Bitcoin address if
you'd like to receive some.

\---

Most code is inherited from Bitcoin, custom code with cryptography:
smessage.cpp, ringsig.cpp and stealth.cpp

~~~
tptacek
People. Come on.

It is OK that you don't know the best curve to use, or that an IV needs to be
included in your MAC.

What is not OK is _shipping privacy code to users_ without understanding this
stuff. You don't get to learn this stuff on the job. Sorry. I know it's not
fair. But to do otherwise would be even less fair to your users.

 _First_ be sure of your crypto. _Then_ set up the bug bounty.

You can donate mine, for the MAC bug (which is severe), to Partners In Health.

------
janimo
Hard to take seriously with all those ambitious goals and talk about privacy
but without https configured on their subdomain.

~~~
Taek
On the other hand, setting up https is a different skill set from the types of
distributed systems that Umbra is trying to be, and I still find it to be
confusing even though things like Let's Encrypt have made the process a lot
easier.

Still, I've been around the space for a long time and I don't remember hearing
too much about the Umbra project before today. That's usually a bad sign,
especially given that they don't have a whitepaper.

There are a few major problems that slaughter projects like this:

1\. They don't respect scalability constraints.

2\. They don't actually understand what it takes to achieve privacy.

3\. They don't realize that they've set up a centralized system.

4\. They don't understand a lot of things about decentralization. This stuff
is hard.

The only whitepaper I could find for the whole system was for ShadowChat,
which says they use AES-256-CBC to encrypt the chat. AES is a symmetric
encryption algorithm, and a strange choice for a chat protocol. Furthermore,
CBC is not great at hiding patterns, and chat will often have a lot of
patterns. Not necessarily going to cause problems, but it's another decision
that I think is pretty weak, especially when there are better standards
already out there.

[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=13&ved=0ahUKEwjYjouplvvOAhWCkh4KHaNID5UQFghHMAw&url=https%3A%2F%2Fgithub.com%2Fshadowproject%2Fwhitepapers%2Freleases%2Fdownload%2F1.0%2FShadowChat.pdf&usg=AFQjCNHONU9jeIqA6_UD7QKKxFSNOg14kg&sig2=vomczSrOjmUdP_1Mlx-
ebw)

[http://crypto.stackexchange.com/questions/25089/plaintext-
bl...](http://crypto.stackexchange.com/questions/25089/plaintext-block-
chaining-bad-idea-why)

As for anonymous cryptocurrency, there have been a lot of attempts at creating
anonymous cryptocurrency and they are generally garbage. Either the mixing
leaks information, or there is a reliance on central services, or other major
problems.

Shadowcash claims to be a Proof-of-Stake cryptocurrency, which is a consensus
system that has been pretty highly discredited among the more well respected
researchers. The threat model is definitely different, and in general is a lot
weaker both in terms of attack-resistance and in terms of decentralization
that traditional Proof-of-Work. Even Ethereum has yet to come up with a Proof-
of-Stake algorithm that they feel comfortable committing to, and they were so
certain they'd get there that they added a feature which will break the
currency unless they hardfork to PoS (at least that was the idea - given that
PoS is not ready, they will probably just hardfork to a not-intentionally-
broken PoW).

[https://download.wpsoftware.net/bitcoin/pos.pdf](https://download.wpsoftware.net/bitcoin/pos.pdf)
[https://download.wpsoftware.net/bitcoin/old-
pos.pdf](https://download.wpsoftware.net/bitcoin/old-pos.pdf)

A few worth taking seriously are Monero, Zcash (though Zcash depends on
new/fancy/less-trusted crypto - zkSnarks), and JoinMarket. Everything else
that's got academic strength behind it is too early to have a user-ready
implementation.

That's just my two cents. Maybe in a few weeks there will be a whitepaper that
covers the full strategies of Umbra and it ends up being pretty good. But I
don't think so, given that the few decisions that I could find already suggest
that this is a platform built by amateurs.

~~~
CiPHPerCoder
> The only whitepaper I could find for the whole system was for ShadowChat,
> which says they use AES-256-CBC to encrypt the chat.

Okay.

> AES is a symmetric encryption algorithm, and a strange choice for a chat
> protocol.

No, it's the standard choice.

Signal uses AES-256-CBC + HMAC-SHA-256, for example.

> Furthermore, CBC is not great at hiding patterns, and chat will often have a
> lot of patterns.

That's not true. CBC mode isn't great at hiding patterns _with IV reuse_.
Solution: Don't reuse IVs.

The problem with CBC mode is that it's unauthenticated, and as a result is
often susceptible to padding oracle attacks that allow messages to be
decrypted byte-at-a-time.

[https://paragonie.com/blog/2015/05/using-encryption-and-
auth...](https://paragonie.com/blog/2015/05/using-encryption-and-
authentication-correctly)

A better mode would be GCM, or maybe GCM-SIV, or scrap AES entirely in favor
of ChaCha20-Poly1305.

~~~
kewde
It's not voiding the cryptographic doom principle, that's one thing. The HMAC
is dealt by OpenSSL it seems and is the hash of the timestamp, destination and
encrypted payload. It's appended outside of the encrypted payload.
[https://moxie.org/blog/the-cryptographic-doom-
principle/](https://moxie.org/blog/the-cryptographic-doom-principle/)
[https://github.com/shadowproject/shadow/blob/master/src/smes...](https://github.com/shadowproject/shadow/blob/master/src/smessage.cpp#L3510)

On the other hand I agree to switching over to a different mode to eliminate
padding oracle attacks.

The IV are 16 random bytes generated by OpenSSL's RAND_bytes.
[https://github.com/shadowproject/shadow/blob/master/src/smes...](https://github.com/shadowproject/shadow/blob/master/src/smessage.cpp#L3364)

~~~
CiPHPerCoder
If one of the project devs is reading this thread:

[https://github.com/shadowproject/shadow/blob/f3fa333f8377688...](https://github.com/shadowproject/shadow/blob/f3fa333f837768823afe16c0347272b5cb8d6c2a/src/util.cpp#L579-L592)

That's really hard to read.

Also, don't use OpenSSL: [https://paragonie.com/blog/2016/05/how-generate-
secure-rando...](https://paragonie.com/blog/2016/05/how-generate-secure-
random-numbers-in-various-programming-languages#c-csprng)

~~~
kewde
Hi,

Yes we're always where the critics are, they are or best source of
information.

I'm very happy to see our work being reviewed. I'm not an expert cryptographer
but I am capable of understanding it. (fyi I didn't code it).

Our memcmp in constant time is not the prettiest, but it's short so we roll
with it :P

This project started around 2014, LibSodium was still very small back then and
OpenSSL, in ours view, remains the defacto standard. Is there any particular
reason on why we should move away from RAND_bytes() ?

~~~
CiPHPerCoder
Yes: Aside from being a userspace CSPRNG (which is an additional risk of
failure over the kernel's CSPRNG and doesn't provide defense-in-depth), it
isn't thread-safe.

[https://github.com/ramsey/uuid/issues/80](https://github.com/ramsey/uuid/issues/80)

[https://github.com/nodejs/node/issues/5798](https://github.com/nodejs/node/issues/5798)

There are also some recent IACR papers (linked in the Node thread), but those
are the two biggest concerns.

~~~
kewde
Thank you CiPHPerCoder!

That link to NodeJS was a good read, I'm fairly convinced that we should ditch
RAND_bytes from OpenSSL for something more secure, we'll look into LibSodium.

I've caught rumours of a possible RAND_sys_bytes which operates over the
systems CSPRNG? We like to be conservative on the libs.

We'd like to tip you for your efforts, do you have a Bitcoin (or ShadowCash)
address?

~~~
CiPHPerCoder
I do, actually, but I haven't accessed it in almost two years. EDIT: And I
forgot my password. Here's a new one:

    
    
      1D6RMsgnTAf2GLWpD91EaQvQ5ppuaZKkGT

------
brokentone
Do we need a payment system and chat client connected as a "platform"? Seems
like an odd collection of things, and can't imagine that a startup would have
reasonable expertise in chat AND payments.

------
gragas
It's probably just me, but this all seems hilariously similar to the "shadow"
metaphor that Comey (FBI Director) mentioned in his speech the other day. I
half-jokingly think this is just an FBI front.

~~~
imglorp
Fully not jokingly, I think governments love BTC and other pseudo-anonymous
blockchain tech in particular. It's a permanent, irrefutable record linking
transactions. Even if your name's not on it, without extreme heroics, you name
will be traceable to the cash end or the service end at some point. This is
way better than cash.

Fully anonymous blockchain tech probably scares them.

------
wyager
> currency

OK, it's an altcoin scam.

Sounds like they don't even have any interesting cryptographic primitives for
privacy, but they just have a mixer built into the app or something. Why would
I use this over using Bitcoin with a mixer? Plus, if/when Bitcoin starts
integrating ZKP/privacy cryptography like Ring signatures, it's going to be a
very hard sell to use any of the miscellaneous altcoins that have some
privacy-related cryptographic advancement as their only feature.

------
CiPHPerCoder
[https://github.com/shadowproject/shadow/blob/4e6affe1457116a...](https://github.com/shadowproject/shadow/blob/4e6affe1457116a70d1e53bfd4cc4d1d2deceea5/src/crypter.cpp#L92-L117)

Ever heard of IND-CCA3?

------
joepie91_
The site doesn't even work with JS disabled. Which is especially important
here, given that a lot of privacy-conscious people _disable JavaScript_ to
prevent fingerprinting.

------
kodablah
Any distributed storage option? Asynchronous chat-style messaging is rarely
enough for social networking.

------
homero
Man another alt coin

------
speps
The URL made me think it had something to do with this instead :
[http://umbra3d.com/](http://umbra3d.com/)

~~~
malkia
Me too. The tech was used in a gamedev company I worked. But I guess this is a
bit of expected, like QT the QuickTime and Qt the UI, and many other cases.

