7 ms·

Umbra Privacy Platform

49 points by agmontpetit 10y ago

CiPHPerCoder 10y ago
https://github.com/shadowproject/shadow/blob/4e6affe1457116a70d1e53bfd4cc4d1d2deceea5/src/crypter.cpp#L92-L117 https://github.com/shadowproject/shadow/blob/4e6affe1457116a... Ever heard of IND-CCA3?
speps 10y ago
The URL made me think it had something to do with this instead : http://umbra3d.com/ http://umbra3d.com/
- malkia 10y ago
  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.
janimo 10y ago
Hard to take seriously with all those ambitious goals and talk about privacy but without https configured on their subdomain.
- Taek 10y ago
  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&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 https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c... http://crypto.stackexchange.com/questions/25089/plaintext-block-chaining-bad-idea-why http://crypto.stackexchange.com/questions/25089/plaintext-bl... 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 10y ago
    > 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-authentication-correctly https://paragonie.com/blog/2015/05/using-encryption-and-auth... A better mode would be GCM, or maybe GCM-SIV, or scrap AES entirely in favor of ChaCha20-Poly1305.
    - kewde 10y ago
      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/smessage.cpp#L3510 https://github.com/shadowproject/shadow/blob/master/src/smes... 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/smessage.cpp#L3364 https://github.com/shadowproject/shadow/blob/master/src/smes...
      - CiPHPerCoder 10y ago
        If one of the project devs is reading this thread: https://github.com/shadowproject/shadow/blob/f3fa333f837768823afe16c0347272b5cb8d6c2a/src/util.cpp#L579-L592 https://github.com/shadowproject/shadow/blob/f3fa333f8377688... That's really hard to read. Also, don't use OpenSSL: https://paragonie.com/blog/2016/05/how-generate-secure-random-numbers-in-various-programming-languages#c-csprng https://paragonie.com/blog/2016/05/how-generate-secure-rando...
- rngesus 10y ago
  I was just about to post this, I'd love to see someone audit their codebase all these claims are super cool and all, but things like these really make it hard to take them serious. Especially when issues like these: https://github.com/shadowproject/shadow/issues/25 https://github.com/shadowproject/shadow/issues/25 pop up. "There is no way to contact you on the bug bounty program"
  - ffmad 10y ago
    Email link were forgotten when the website was upgraded. And issue was answered.
gragas 10y ago
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 10y ago
  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 10y ago
  Almost certainly a reference to https://en.wikipedia.org/wiki/Penumbra_(law) https://en.wikipedia.org/wiki/Penumbra_(law) This is probably the single most significant concept for legal privacy rights in the US.
- pmontra 10y ago
  Umbra, shadow, IMHO that sort of names don't have a very positive connotation for the general public. How about calling the next one Lux, light or something like that? Maybe not priming people with the idea that those tools will be used only for shadowy business can help their success.
kodablah 10y ago
Any distributed storage option? Asynchronous chat-style messaging is rarely enough for social networking.
wyager 10y ago
> 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.
homero 10y ago
Man another alt coin
brokentone 10y ago
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.
tptacek 10y ago
If this is their chat scheme: https://github.com/shadowproject/whitepapers/releases/download/1.0/ShadowChat.pdf https://github.com/shadowproject/whitepapers/releases/downlo... ... 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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        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?
joepie91_ 10y ago
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.

49 points by agmontpetit 10y ago

https://github.com/shadowproject/shadow/blob/4e6affe1457116a70d1e53bfd4cc4d1d2deceea5/src/crypter.cpp#L92-L117 https://github.com/shadowproject/shadow/blob/4e6affe1457116a... Ever heard of IND-CCA3?

speps 10y ago

The URL made me think it had something to do with this instead : http://umbra3d.com/ http://umbra3d.com/

malkia 10y ago
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.

janimo 10y ago

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

Taek 10y ago
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&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 https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c... http://crypto.stackexchange.com/questions/25089/plaintext-block-chaining-bad-idea-why http://crypto.stackexchange.com/questions/25089/plaintext-bl... 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 10y ago
  > 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-authentication-correctly https://paragonie.com/blog/2015/05/using-encryption-and-auth... A better mode would be GCM, or maybe GCM-SIV, or scrap AES entirely in favor of ChaCha20-Poly1305.
  - kewde 10y ago
    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/smessage.cpp#L3510 https://github.com/shadowproject/shadow/blob/master/src/smes... 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/smessage.cpp#L3364 https://github.com/shadowproject/shadow/blob/master/src/smes...
    - CiPHPerCoder 10y ago
      If one of the project devs is reading this thread: https://github.com/shadowproject/shadow/blob/f3fa333f837768823afe16c0347272b5cb8d6c2a/src/util.cpp#L579-L592 https://github.com/shadowproject/shadow/blob/f3fa333f8377688... That's really hard to read. Also, don't use OpenSSL: https://paragonie.com/blog/2016/05/how-generate-secure-random-numbers-in-various-programming-languages#c-csprng https://paragonie.com/blog/2016/05/how-generate-secure-rando...
rngesus 10y ago
I was just about to post this, I'd love to see someone audit their codebase all these claims are super cool and all, but things like these really make it hard to take them serious. Especially when issues like these: https://github.com/shadowproject/shadow/issues/25 https://github.com/shadowproject/shadow/issues/25 pop up. "There is no way to contact you on the bug bounty program"
- ffmad 10y ago
  Email link were forgotten when the website was upgraded. And issue was answered.

gragas 10y ago

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 10y ago
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 10y ago
Almost certainly a reference to https://en.wikipedia.org/wiki/Penumbra_(law) https://en.wikipedia.org/wiki/Penumbra_(law) This is probably the single most significant concept for legal privacy rights in the US.
pmontra 10y ago
Umbra, shadow, IMHO that sort of names don't have a very positive connotation for the general public. How about calling the next one Lux, light or something like that? Maybe not priming people with the idea that those tools will be used only for shadowy business can help their success.

kodablah 10y ago

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

wyager 10y ago

> 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.

homero 10y ago

Man another alt coin

brokentone 10y ago

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.

tptacek 10y ago

If this is their chat scheme: https://github.com/shadowproject/whitepapers/releases/download/1.0/ShadowChat.pdf https://github.com/shadowproject/whitepapers/releases/downlo... ... 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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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?

joepie91_ 10y ago

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.