Phone Encryption - Open Whisper Systems

Discussion in 'Technical' started by Ganado, Jul 29, 2015.


  1. Ganado

    Ganado Monkey+++

    Anyone have experience with phone encryption? I used silent phone for a while but they retired the texting system so I ve been looking for a substitute. Someone pointed me to this one but it's apparently not open source
    Encrypt calls on your Android device with RedPhone - TechRepublic
     
  2. melbo

    melbo Hunter Gatherer Administrator Founding Member

    If it's not open source, I wouldn't trust it.
    I don't use anything that includes voice at this time
     
    Ganado likes this.
  3. wnn

    wnn Guest

    Never used an app. Depending on maker of phone (motorola) mine has encypt feature built in if i activate it.
     
  4. melbo

    melbo Hunter Gatherer Administrator Founding Member

    This looks interesting - voice and text
    Open Whisper Systems >> Home
    Open Whisper Systems · GitHub
    Open WhisperSystems | Freedom of the Press Foundation

    TextSecure uses Curve25519, AES-256, and HMAC-SHA256. The security of these algorithms has been tested over many years of use in hundreds of different applications. Messages sent via TextSecure are end-to-end encrypted, which means that they can only be read by your intended recipients. We make it easy for you to verify that you are communicating with the right people and that no MITM attack has occurred. The keys that are used to encrypt your messages are stored on your device alone, and they are protected by an additional layer of encryption if you have a passphrase enabled.

    Open WhisperSystems does not have access to the contents of any messages sent by TextSecure users. Additionally, the complete source code for the TextSecure clients and the TextSecure server is available on GitHub. This enables interested parties to examine the code and help us verify that everything is behaving as expected. It also allows advanced users to compile their own copies of the applications and compare them with the versions we distribute.

    The Axolotl ratchet in TextSecure is the most advanced cryptographic ratchet available. Axolotl ensures that new AES keys are used for every single message, and it provides TextSecure with both forward secrecy and future secrecy properties. The TextSecure protocol also features enhanced deniability properties that improve on those provided by OTR, except unlike OTR all of these features work well in an asynchronous mobile environment.

    We believe that V2 of the TextSecure protocol represents the current state of the art in secure messaging.
     
    Last edited: Aug 9, 2015
    Ganado likes this.
  5. melbo

    melbo Hunter Gatherer Administrator Founding Member

    Open Whisper Systems - Wikipedia, the free encyclopedia
     
    Ganado likes this.
  6. Ganado

    Ganado Monkey+++

    @melbo you are my hero! Ty ty ty
     
  7. melbo

    melbo Hunter Gatherer Administrator Founding Member

  8. melbo

    melbo Hunter Gatherer Administrator Founding Member

    The best part is that you don't need to really understand how this works to use it which is a huge step forward for encrypted communications.

    Open Whisper Systems >> Blog >> Simplifying OTR deniability.

    Simplifying OTR deniability.
    At Open Whisper Systems we help develop TextSecure, an encrypted chat application for Android. TextSecure was designed as a general purpose SMS/MMS client which would also automatically encrypt conversations when communicating with other TextSecure users. For those encrypted sessions, TextSecure uses a compact derivative of the well known OTR protocol.

    We’re currently in the process of transitioning TextSecure to use a device’s data channel as a transport for communication with other TextSecure users whenever possible. This enables communication with the upcoming TextSecure for iOS, helps users avoid SMS fees, and obscures conversation metadata from telcos.

    The transition to a new transport is also a good opportunity for us to evaluate and introduce additional cryptographic protocol changes. Below is one cryptographic protocol change we’re thinking of making that we’d welcome feedback on.

    OTR Today
    One of OTR’s primary features is a property called deniability. If someone receives an OTR message from you, they can be absolutely sure you sent it (rather than having been forged by some third party), but can’t prove to anyone else that it was a message you wrote. This is a nice change compared to PGP signatures, for instance, where anyone who receives a PGP signed message can prove exactly who wrote it to anyone else.

    Let’s see how this works. A simplified version of the initial OTR key exchange looks like this:
    image.
    Each participant has a long-term identity key (A and B) that they use to sign an ephemeral key (a and b), which they exchange and use to calculate a shared secret. In reality, this initial exchange is more complex, since it actually happens inside another ephemeral key exchange (for privacy reasons), but this is the basic thrust of it.

    The shared secret from this key exchange is used to derive a sending and receiving cipher key for each party, as well as a set of MAC keys for each party. Every transmitted message includes a MAC, which the message’s recipient can verify. Since the key used to construct and verify the MAC was derived from the shared secret, and since the shared secret was derived from a key exchange that was in turn signed by the sender’s long-term identity key, the recipient can be sure that the message was really constructed by their peer in the conversation.

    The message is “deniable,” however, because the MAC keys are derived from a shared secret. Unlike PGP signatures, where the sender is the only person capable of producing the signature, the recipient of an OTR message is alsocapable of producing a sender’s MAC. This doesn’t compromise the integrity of the conversation for its participants, but does prevent a message’s recipient from revealing the MAC’d message to a third party as proof that it was produced by the sender, since it could have just as easily been constructed by the recipient themselves. Exactly what we want.

    OTR’s deniability efforts don’t stop there, however. As a conversation progresses, OTR’s key material will continually roll forward (for ongoing forward secrecy), and every time a conversation’s MAC keys roll forward, OTR publishes the old ones onto the wire in the clear. The idea being that, given old MAC keys, any passive observer could technically modify old ciphertext and produce forged but valid MACs for it, which increases a message’s plausible deniability without compromising a conversation’s integrity (since those old MAC keys can’t be used for new messages).

    Limitations
    As implementors of a protocol that’s derivative of OTR, there are a few things that we haven’t been satisfied with.

    Complexity
    OTR uses a Diffie-Hellman key exchange of ephemeral keys, signed by long-term identity keys. While Diffie-Hellman is remarkably simple, DSA (used to calculate those identity key signatures) is not nearly as simple, and is often easy to fuck up. It’d be nice to avoid subjecting ourselves to that increased complexity if we can.

    Additionally, publishing old MAC keys in the clear is a somewhat strange contortion for a protocol to make, and has a dangerous feeling associated with it. Ephemeral or not, it seems like it’d be ideal if all our secrets could remain secret. We’d be happy if it were possible for us to eliminate that added protocol complexity as well.

    Limited Forgability
    Presumably, OTR goes through the contortions of publishing old MAC keys to increase an old message’s forgability, which should strengthen that message’s deniability (if anyone could have forged it, it’s easier to deny). However, it’s not entirely clear how this works in practice.

    It’s true that by publishing old MAC keys, anyone is capable of modifying the ciphertext of a previously observed message. However, even if that person can guess the plaintext and is capable of making predictable modifications to the ciphertext via a malleable encryption scheme, they still can’t demonstrate valid plaintext to anyone else without the cipher keys (and if they had those, they would be able to calculate the MAC keys anyway).

    What’s more, since the initial OTR key exchange is signed and transmitted through an unobservable channel (an “outer” ephemeral key exchange), it’s not actually possible for anyone to produce what appears to be a conversation with you. Only people you’ve actually had a conversation with are in possession of a signed ephemeral key from you, and are thus the only ones capable of producing plaintext messages attributed to you. Publishing old plaintext MAC keys in the clear does not substantially increase this set of people’s ability to forge messages from you, since they are already in possession of the MAC keys.

    So even after going through the contortions of publishing plaintext MAC keys, the set of people capable of producing forged messages from a sender is still just the set of people who’ve actually received messages from that sender.

    Potential Simplifications and Improvements
    The inimitable Trevor Perrin turned us on to a trick that we can use to greatly simplify and improve OTR’s deniability property. All it takes is modifying the initial key exchange from this:
    image.
    To this:
    image.

    This replaces two DSA signatures and one Diffie-Hellman exchange with three Diffie-Hellman exchanges. Each participant still has a long-term identity key (A and B) and an ephemeral key (a and b). However, instead of signing the ephemeral keys, participants simply exchange both unsigned keys (gA,ga) and (gB,gb) to calculate three shared secrets: gaB, gAb, and gab.

    By then using all three shared secrets as one combined seed to the initial KDF, we accomplish the following:

    1. Reduced Algorithmic Complexity. We’ve eliminated DSA and have a nice authenticated key exchange that relies solely on the simplicity of Diffie-Hellman.
    2. Increased Forgability. Since there are no signatures involved, anyone could take A’s public key, make up an ephemeral keypair for A (“a” in the diagram above), combine that with their own identity key and ephemeral key (“C” and “c”), and produce an entire forged transcript – even if they’ve never had a conversation with “A” before. Now anyone is capable of easily producing a forged message from anyone else, whether they’ve actually had a conversation with them before or not.
    3. Reduced Protocol Complexity. Since anyone is capable of using only someone’s public identity key to produce an entire forged conversation, there is no need to publish old MAC keys in the clear any longer. Our secrets can remain secret, and we can eliminate that somewhat odd bit of protocol complexity.
    4. Maintained Forward Secrecy. Since an ephemeral handshake is part of the KDF seed, the compromise of an identity key will still never result in the compromise of previously transmitted ciphertext – or even passive observation of future ciphertext.
    5. Smaller Payloads. Instead of transmitting an identity key, an ephemeral key, and a signature during the handshake, one only needs to transmit an identity key and an ephemeral key, reducing the payload by the size of the signature (a significant amount for transports like SMS). Additionally, subsequent message payload sizes are also reduced, since broadcasting plaintext MAC keys is no longer necessary.
    We found Trevor’s suggestion to have surprising results. With one small change to the initial key exchange, we can reduce its complexity (no more DSA), eliminate publishing old MAC keys in the clear, increase deniability by increasing forgability, and reduce payload size – all without increasing the number of round trips required or introducing any other additional complexity.

    We’re currently looking at integrating this change into the next version of the TextSecure protocol, along with a number of other improvements for asynchronous communication that we’ll write more about later.

    Moxie Marlinspike, 27 July 2013
     
    VisuTrac, BTPost and Ganado like this.
  9. melbo

    melbo Hunter Gatherer Administrator Founding Member

    Open Whisper Systems - Wikipedia, the free encyclopedia

    Former NSA contractor Edward Snowden has endorsed Open Whisper Systems' applications on multiple occasions. In his keynote speech at SXSW in March 2014, he praised TextSecure and RedPhone for their ease-of-use.[29] During an interview with The New Yorker in October 2014, he recommended using "anything from Moxie Marlinspike and Open Whisper Systems".[30] During a remote appearance at an event hosted by Ryerson University and Canadian Journalists for Free Expression in March 2015, Snowden said that Signal is "very good" and that he knew the security model.[31]Asked about encrypted messaging apps during a Reddit AMA in May 2015, he recommended “Signal for iOS, Redphone/TextSecure for Android”.[32][33]

    In October 2014, the Electronic Frontier Foundation (EFF) included TextSecure, RedPhone, and Signal in their updated surveillance self-defense guide.[34] In November 2014, all three received top scores on the EFF's secure messaging scorecard, along with Cryptocat, Silent Phone, and Silent Text.[35]They received points for having communications encrypted in transit, having communications encrypted with keys the providers don't have access to (end-to-end encryption), making it possible for users to independently verify their correspondent's identities, having past communications secure if the keys are stolen (forward secrecy), having their code open to independent review (open source), having their security designs well-documented, and having recent independent security audits.[35]

    On December 28, 2014, Der Spiegel published slides from an internal NSA presentation dating to June 2012 in which the NSA deemed RedPhone on its own as a "major threat" to its mission, and when used in conjunction with other privacy tools such as Cspace, Tor, Tails, and TrueCrypt was ranked as "catastrophic," leading to a "near-total loss/lack of insight to target communications, presence..."[36][37]
     
    VisuTrac, BTPost and Ganado like this.
  10. William Warren

    William Warren Monkey+++

    "Off The Record" (OTR) is an interesting idea, but I don't know if it's a productive approach to securing text messages or voice calls. I'm no expert, but there are things that concern me when I read about OTR protocols.

    The explanation of the key exchanges doesn't seem to indicate a new or revolutionary method: every Public-Key system must generate and exchange ephemeral (a.k.a. "Session") keys, since the public key algorithm are too computationally intense to be used for any real time service.

    I guess I don't get it: this seems like a solution in search of a problem, so someone please tell me what I'm missing.

    William Warren
     
  11. melbo

    melbo Hunter Gatherer Administrator Founding Member

    BTPost likes this.
  12. BTPost

    BTPost Stumpy Old Fart,Deadman Walking, Snow Monkey Moderator

    The newer NSA Hardware is making RSA KeySet of less than 256 Bits, Brute Force crackable in just hours, instead of months. If they are given a hint of the PassPhrase, that can extend to 1024 Bit KeySets.... 4096 Bit KeySets are the minimum in today's world. OTR keeps those KeySets off the Comms Channel, and therefore, better Secured. Looking forward to the IOS version, coming soon.... For both Data and Voice...
     
  13. melbo

    melbo Hunter Gatherer Administrator Founding Member

    Do you have a source for this?
    I don't disagree but have found that even AES-128 is still only NSA crackable in theory and not yet a reality.

    I personally use 4096 or now 8192 for keys these days.

    Summoning @sec_monkey for comment
     
  14. BTPost

    BTPost Stumpy Old Fart,Deadman Walking, Snow Monkey Moderator

    Not that I am willing to divulge, in this day and age.... The Hardware has just one purpose, To factor Cypher KeySets.... Via MultiProcessors, in GigaGiant Arrays.... Your Tax FRNs at work.....
     
  15. William Warren

    William Warren Monkey+++

    I've heard that recommendation from others, and thanks for passing it on.

    I'm a bit behind (pun intended) the curve here: since the actual message is sent with a symmetric cipher like AES, isn't it easier to brute-force the session key?

    William Warren
     
  16. William Warren

    William Warren Monkey+++

    I get that part, but AFAIK, PGP does the same thing: each message is encrypted with a random session key that is never used again. How is OTR different?

    The second Wikipedia article says:

    Deniable authentication: Messages in a conversation do not have digital signatures, and after a conversation is complete, anyone is able to forge a message to appear to have come from one of the participants in the conversation, assuring that it is impossible to prove that a specific message came from a specific person. Within the conversation the recipient can be sure that a message is coming from the person they have identified.
    ... and that just doesn't seem like a good approach to me. I understand that an unsigned message can't be proven to have come from the sender, but that's just part of the public-key algorithm, so any unsigned message would qualify under that definition. If I understand the OTR description correctly, the "session" key is published after the message is sent, but session keys are for the symmetric ciphers that underlay the public-key system, and if they're published, then anyone could not only create another message that appears to have come from the originator, but could also decrypt the original message.

    I'm confused.

    Here are a couple of "Sour grapes" comments, just so salve my pride:

    1. If Adam sends a message to Betty, and then Clarisse creates a false message purportedly from Betty and sends it to Adam, how will Adam detect the forgery? The OTR protocol claims that it's deniable because a third party could create an encrypted message that appears to come from the originator, so where does that leave Adam when he gets a message that he thinks if from Betty?
    2. If the idea of OTR is to provide legal deniability, i.e., to give Adam a way to say that the message could, by design, have been forged, how does Adam deal with the obvious threats of rubber-hose cryptography? I mean, let's be real: once the FBI puts a collar on Adam, he's not going to be thinking about proving that OTR is a valid technical concept! Once the feds know who Adam is, they can spend months going through every detail of his life, finding everyone he is "friends" with on Facepage, going through his credit card, telephone LUDs, and bank records to find coincidental travel and/or lodging that matches some heavyweight they also want. That's not a real attack on the OTR system, of course, but it is a valid concern for someone trying to put together a secure system.
    William Warren
     
    Ganado likes this.
  17. hitchcock4

    hitchcock4 Monkey++

    I realize that my topic isn't encryption --- but items below could help those that like "burner" phone numbers.

    Has anyone used the "Burner" app on iPhone or Android? I just saw a similar app called "Hushed" which can provide a "burner" phone number that you use for a few days, or maybe to give out to specific people.
    Considering getting a lifetime subscription to the Hushed app, which is "on sale" right now at Hushed Private Phone Number: Lifetime Subscription | Neowin Deals.
    Of course, anyone like me considering this for $49 always has to ask -- how long will the company be in business? I saw an article from when Hushed arrived on the scene, about 2.5 years ago (decent, that means they could be around for a good while to come).

    Thanks!
     
    Ganado likes this.
  18. 10brokenpromises

    10brokenpromises Monkey++

    The issue with a burner number is that it's still the same IMEI number from your "parent" phone and can be traced back to you via cell tower records. The real reason for a burner phone is to not have the number tied to you. Considering that you can buy a burner for cash at the grocery store for less than $5 and other than surveillance video there's no way to tie it to you, why would I go the other route?

    All 3 local grocery stores plus both of the pharmacy chains sells prepaid cellular service and yes, several times a year there are phones on clearance for $4.95 and they ALWAYS come with both free minutes and codes to double any minutes you buy...always.

    Consider why you want a burner. Do you want a burner number that goes away after a fixed amount of time that you can use to "register" for stuff but not get hassled? Or do you want a phone that is more difficult to trace back to you, for whatever reason?

    Things to consider about a burner phone. Having both phones (primary and burner) on and getting signal at the same time right next to each other completely defeats the purpose. Based on signal strength and triangulation they can put both your primary phone and the burner at the same location and now you've totally blown any shred of anonymity you may have had (think Walter White in Breaking Bad...a primary in one pocket and a burner in the other...NOT criminal mastermind of the year and Saul was no better with a drawer full of them all turned on...sheesh!).

    Oh, and don't pay for the phone with a debit card (unless it's prepaid with bogus info) nor the minutes and for the love of PETE, please don't register the stupid thing.

    Burner App = Security/Anonymity Theater.
     
    Yard Dart and Ganado like this.
  19. Ganado

    Ganado Monkey+++

    I am watching and reading this thread. I have to re-read some of it aaalot.
    @10brokenpromises I've been looking at this issue because I don't need my texts tracked or hijacked.

    The entire thread is about info and what's available so I can make informed decisions regarding how my info is shared. Love my smart phone but it's very invasive about gathering info even after I rooted it and scaled it back.

    So for me considering all available software and options and discussing their pro's and cons is invaluable.

    And thanks for pointing out IMEI issue with using the same phone. :)
     
  20. hitchcock4

    hitchcock4 Monkey++

    Thanks for the info on the IMEI, I hadn't thought all of that through, ha-ha. Right now, I'm interested in having multiple numbers, so I think this will do. But I will be watching the sales, as you mention, for a real burner in case the need arises. Cool, thanks.
     
    Ganado likes this.
  1. DKR
  2. William Warren
  3. Ganado
  4. bumpshadow
  5. hitchcock4
  6. DKR
  7. Bandit99
  8. HK_User
  9. BTPost
  10. DKR
  11. BenP
  12. Hanzo
  13. Asia-Off-Grid
  14. Motomom34
  15. Asia-Off-Grid
  16. ED GEiN
  17. ED GEiN
  18. Motomom34
  19. BenP
  20. Motomom34
survivalmonkey SSL seal        survivalmonkey.com warrant canary
17282WuJHksJ9798f34razfKbPATqTq9E7