Slashdot Mirror


Phil Zimmermann's New App Protects Smartphones From Prying Ears

Hugh Pickens writes "Neal Ungerleider notes that cryptography pioneer and Pretty Good Privacy (PGP) creator Phil Zimmermann has launched a new startup that provides industrial-strength encryption for Android and iOS where users will have access to encrypted phone calls, emails, VoIP videoconferencing, SMS, and MMS. Text and multimedia messages are wiped from a phone's registry after a pre-determined amount of time, and communications within the network are allegedly completely secure. An 'off-shore' company with employees from many countries, Silent Circle's target market includes troops serving abroad, foreign businesspeople in countries known for surveillance of electronic communications, government employees, human rights activists, and foreign activists. For encryption tools, which are frequently used by dissidents living under repressive regimes and others with legitimate reasons to avoid government surveillance, the consequences of failed encryption can be deadly. 'Everyone has a solution [for security] inside your building and inside your network, but the big concern of the large multinational companies coming to us is when the employees are coming home from work, they're on their iPhone, Android, or iPad emailing and texting,' says Zimmermann. 'They're in a hotel in the Middle East. They're not using secure email. They're using Gmail to send PDFs.' Another high-profile encryption tool, Cryptocat, was at the center of controversy earlier this year after charges that Cryptocat had far too many structural flaws for safe use in a repressive environment."

121 comments

  1. exceptionally interesting and useful by Anonymous Coward · · Score: 5, Interesting

    for those of us who prize our anonymity. I do hope they'll take Bitcoin for the $20/month they charge.

    1. Re:exceptionally interesting and useful by Anonymous Coward · · Score: 0

      This does not provide anonymity, only point to point security (so no one can read your texts or listen in on your calls).

  2. An old saying comes to mind by Anonymous Coward · · Score: 0

    Beware of strangers bearing gifts. . .

    1. Re:An old saying comes to mind by Anonymous Coward · · Score: 0

      -1 Red Herring

    2. Re:An old saying comes to mind by Anonymous Coward · · Score: 0

      I don't think they're Greek, so the actual old saying doesn't really apply.

  3. RedPhone by Anonymous Coward · · Score: 1

    RedPhone was a decent encrypted voice call tool. It was always beta and eventually stopped working. (Servers pulled, as was the app).

    I believe Phil Z was also the author of RedPhone.

    Sad to see such a restrictive pricing model for the new "solution".

    1. Re:RedPhone by Anonymous Coward · · Score: 0

      RedPhone used a protocol developed by Phil Zimmermann (ZRTP), but he had no involvement in the development of RedPhone (you might be thinking of ZPhone).

    2. Re:RedPhone by Anonymous Coward · · Score: 0

      It looks as though RedPhone is back. I haven't tried it again but it you are interested follow this link: http://www.whispersys.com/

  4. Whatever by nehumanuscrede · · Score: 1, Insightful

    There is no way on this fucking EARTH the powers that be ( read that governments ) are going to let anything tarnish the holy grail of surveillance tech that people stand in line for weeks to buy of their own accord.

    Birthers will recind their claim against Obama, Dawkins will get Baptised, and Ron Paul elected president before this will happen.

    Rest assured, if it DOES, it is with full blessings of the aforementioned governments.

    1. Re:Whatever by gweihir · · Score: 4, Interesting

      That is another valuable experience Zimmermann brings to the table: They tried pretty hard to suppress PGP and he prevailed. I remember than in order for him to not go to jail, it was exported as printed book and then scanned in Europe. He used the stupidity of the US bureaucracy against them. Development continued outside of the US afterwards. That was the time when the US snoops wanted backdoors into any crypto.

      I think is will be interesting to watch, but I expect he will make it again.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re:Whatever by Zero__Kelvin · · Score: 1

      Unless you were trying to be facetious, you clearly don't actually know who Phil Zimmerman is or what he had already done. He has been a major force in the upset of the government's attempts to stop strong crypto already. There is no reason to believe that is about to stop now.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    3. Re:Whatever by muckracer · · Score: 1

      > and Ron Paul elected president before this will happen.

      FOUR MORE WEEKS, FOUR MORE WEEKS...!! :-D

    4. Re:Whatever by muckracer · · Score: 3, Insightful

      >> and Ron Paul elected president before this will happen.

      > FOUR MORE WEEKS, FOUR MORE WEEKS...!! :-D

      Of course this was meant as a joke. ;-)
      We all know, that in reality Gary Johnson (L) will be elected President! And then we don't need to encrypt our phone calls anymore...at least not because of the government snoops, because Pres. Johnson has shut them all down! :-)

  5. Is this thing on? by wirefall · · Score: 1

    Why would a government wiretapper need to intercept your phone call? Wouldn't they just mandate that your provider give them access to your device to record anything going to your mic? In fact, this would minimize the amount of audio they'd have to sift through...If Silent Circle call, then record audio from mic.

    1. Re:Is this thing on? by olsmeister · · Score: 1

      No, the government would never do something like that.

    2. Re:Is this thing on? by Anonymous Coward · · Score: 0

      Wouldn't they just mandate that your provider give them access to your device

      Eh, I'd be very interested to see how my provider would get access to my device.

    3. Re:Is this thing on? by wirefall · · Score: 1

      So you're rockin' a custom ROM? Only because they allow you to. Simple for a provider to disallow anything they don't approve of. If G-DOG says they are required to provide X-access, and your custom ROM doesn't let them...then YOU don't have access. Not true?

    4. Re:Is this thing on? by Sloppy · · Score: 1

      Wouldn't they just mandate that your provider give them access to your device to record anything going to your mic?

      That's one of the reasons people have been advocating for years, that it's undesirable/borderline_senseless to buy your PC from your ISP. In some contexts (PC sits on a desk) people get that and think the idea is absurd and they never would do it, and in others (PC fits in a pocket) it's routine and people don't give it a second thought. Weird.

      But even so, that risk isn't absolute. Not all adversaries are the government, and "the government" isn't always the one government (e.g. is Iran capable of pressuring all the same parties that US is capable of pressuring?).

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    5. Re:Is this thing on? by Anonymous Coward · · Score: 0

      The backdoors aren't necessarily at the ROM level....

  6. Not a good solution- by a long shot. by Anonymous Coward · · Score: 0

    Might I remind people that cell phones are tracking devices.

    1. Modems should not communicate with cell towers until calls are made
    a. There is no way to receive incoming calls anonymously and not be tracked given the design of cellular communications networks.
    b. Solution to this is to not receive calls or:
    b1. Set it up so that phones use data-only prepaid phone 'cards' and open the modem up to 'mac address spoofing'. This is illegal although I bet there is a way it could be done legally. If a company 'owns' a certain segment of MACs then they should sell them. .001 cent a mac address. You wouldn't be stealing service since that has to be activated with a prepaid card.
    b2. Connect to an onion server on Tor. This server could be private and host your text messages. The way the call would be received would be through automatically being turned on every 15 – 60 minutes and pulling text messages from an encrypted onion on Tor or similar system. A system of 'informing' a device when to turn on in order to receive a call could also be designed. This would reduce the opportunity for tracking and users could still 'receive calls' although not in real time. It would only be at certain times.

  7. Closed Source. by Anonymous Coward · · Score: 1

    If you trust closed source security software... good luck.

    1. Re:Closed Source. by jdogalt · · Score: 2

      If you trust closed source security software... good luck.

      Indeed. After Dave Schroeder, a Navy Information Warfare Officer[1], recently gave me Vint Cerf's email address, I posited in a 35 page manifesto[2] that ssh + IPv6 + gstreamer would make a good open source encrypted video network phone solution. Of course I haven't actually tried it, and no doubt the performance would initially suck. But I imagine a week of tuning parameters and you'd have something usable (when need dictates). And in a year if it caught on, I'm sure the performance would probably become excellent. Of course, it kind of helps to have a 'network neutral'(my definition as per manifesto) broadband connection and an IPv6 'server' process listening on your device for incoming connection requests (a.k.a. phone calls). In any event, interesting to see this slashdot article a couple days later.

      [1]
      http://news.slashdot.org/comments.pl?sid=3156485&cid=41516877
      http://news.slashdot.org/comments.pl?sid=3156485&cid=41530745

      [2]
      http://cloudsession.com/dawg/downloads/misc/kag-draft-2k121007.pdf
      http://cloudsession.com/dawg/downloads/misc/kag-draft-2k121007.txt
      http://cloudsession.com/dawg/downloads/misc/kag-draft-2k121001.pdf
      http://cloudsession.com/dawg/downloads/misc/kag-draft-2k121001.txt

  8. You mean like Burner for iOS? by SuperKendall · · Score: 5, Informative

    I doubt it. Our apple overlords will categorise this as 'Undesirable' as it allows their phone users to communicate in ways that they want

    It's funny how so many things people seem to doubt Apple would ever approve, actually get approved. Like for instance a virtualized burner phone, an app that provides you a temporary number lasting a week or as long as you see fit.

    There's already a ton of precedent for Apple to approve something like Silent Circle, and a ton of people like yourself in the dustbin of failed predictions claiming Apple will not accept product X because, well, Apple.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:You mean like Burner for iOS? by Anonymous Coward · · Score: 0

      Umm if it is broken or Apple has a profit incentive they might approve it. I guess that is how we can determine if it is something we can trust.

    2. Re:You mean like Burner for iOS? by Jessified · · Score: 5, Insightful

      And how many seemingly innocuous apps are denied, when we would predict they should be fine?

      Maybe it will be approved...maybe it won't. Nobody can predict it because their rules are so arbitrary. And that, I imagine, is GP's point.

  9. Failsafe encryption requires no MitM by mark-t · · Score: 1

    If you want complete failsafe encryption, the two devices must either be physically connected by wire, or else must broadcast wirelessly directly to eachother, with no repeater or any other physical device not under the complete control of either endpoint in between them.

    Protocols can be devised in such systems which are completely eavesdrop tolerant, such that even if eavesdropping did occur, it would be indecipherable, even if one were to try to listen to the entire communication, including the protocol setup itself, it would sound like undecipherable gibberish right from the moment that the encryption began.

    Such protocols can be vulnerable to MitM attacks, but that is why they are really only reliable as encryption when the communication is not subjected to any routing.

    1. Re:Failsafe encryption requires no MitM by Anonymous Coward · · Score: 0

      If you want complete failsafe encryption, the two devices must either be physically connected by wire, or else must broadcast wirelessly directly to eachother, with no repeater or any other physical device not under the complete control of either endpoint in between them.

      I think you are wrong about that. There is no such thing as point-to-point wireless. I will even claim that wireless is just as bad as an untrusted infrastructure, probably worse that that.

    2. Re:Failsafe encryption requires no MitM by thestuckmud · · Score: 3, Informative

      This isn't Zimmerman's first time around the block. His Zrtp protocol for SIP (VOIP) security includes Short Authentications Strings which can be communicated by voice or even out of channel, as well as shared secrets from previous connections. These offer reasonable protection against man in the middle attacks.

    3. Re:Failsafe encryption requires no MitM by Anonymous Coward · · Score: 1

      If you want complete failsafe encryption, the two devices must either be physically connected by wire, or else must broadcast wirelessly directly to eachother, with no repeater or any other physical device not under the complete control of either endpoint in between them.

      That isn't practical, and definitely not as secure as you think. And wireless is NOT secure from a man in the middle attack, ever. It doesn't matter if the sender and receiver are unidirectional. The purpose of a MiM attack can be something deceptively simple, like spoofing GPS (and we all know what that can do). The attacker only needs to interrupt the communication or overpower the real transmitter to wreak havoc.

      Your idea of being in complete control of endpoints is silly. Bugs can intercept anything, wired or wireless. It doesn't always require physical access to the wire (depending on it's length, it acts as an antenna). Repeaters, routers and hubs, etc. are obviously weak links for secure communication, but these things only make it easier to eavesdrop.

      If you setup any of the systems you're promoting, it'll attract attention. If your whole purpose is to communicate securely, then being conspicuous is not helping.

      If somebody wants to eavesdrop badly enough, they can. This is usually a result of attracting bad attention, which if you're smart you can avoid in most cases.

      Practically and realistically, you could just email the sensitive information in an attachment that's AES256 encrypted (or better). It's not horribly conspicuous, at least. I sometimes use 7zip (7z/AES256) for this purpose and I'm not aware of any serious vulnerabilities. Yes, it can be decrypted by a man in the middle, but not quickly. Everything sensitive becomes less so over time, so if enough time passes (a couple days, months or years) then it doesn't matter anymore. Avoid using too many details or full explanations, leave things slightly ambiguous so that if it's inevitably decrypted it proves to be mostly a waste of the eavesdropper's time.

      (Just never use zip/pkcrypt, it's laughably insecure.)

    4. Re:Failsafe encryption requires no MitM by gnoshi · · Score: 1

      Actually, if you want completely failsafe encryption (excluding actually cracking the key itself) you need two three things:
      1. Trusted endpoints (i.e. devices that you can trust - this is quite a challenge itself)
      2. *One* interaction guaranteed to be protected from a MiTM for key exchange
      3. An encryption protocol which isn't broken

      #3 is easy. There are multiple options available.
      #2 can be easy, if you live just down the road from the person you want to have secure communication with. It can also be hard if you can never meet the intended recipient.
      #1 is a nightmare, unless you build the device and the OS yourself.

      The actual communication path can be anything from public radio broadcast to RFC1149, so long as the endpoints are trusted, the encryption protocol isn't broken, and your key exchange hasn't been intercepted (or keys stolen, but that is a trusted endpoint issue)

    5. Re:Failsafe encryption requires no MitM by MrNaz · · Score: 1

      Actually, that's not correct. You do not need even one guaranteed interaction in order to establish an encrypted channel. Diffie-Hellman key exchange is pretty secure, as long as your encryption protocol is not broken.
      Whatever the circumstances, you need trusted endpoints, and you need a viable encryption protocol. You need those two. Not two out of a set of three, which include those. Untrusted endpoints means you're open to side channel attacks or simple bugging. Even if you have bulletproof protocols and 100% trusted interaction, it's no help if your endpoints have keyloggers sending their data to Eve.

      --
      I hate printers.
    6. Re:Failsafe encryption requires no MitM by mark-t · · Score: 2

      Radio can be point-to-point. You can't exactly intercept an airborne signal and try to relay it without building a shield large enough to fully encompass the sender. Something that they would readily be aware of.

    7. Re:Failsafe encryption requires no MitM by mark-t · · Score: 1
      No... you can make communication on an otherwise completely open channel 100% eavesdrop-proof (to the extent that the discrete logarithm problem is not solvable for in a large domain of numbers in real-time).

      And wireless point to point is not remotely difficult.... all you need is a transmitter and antenna that are strong and large enough to reach any reachable destination. CB can even be point-to-point quite easily.

    8. Re:Failsafe encryption requires no MitM by Electricity+Likes+Me · · Score: 2

      Radio can be point-to-point. You can't exactly intercept an airborne signal and try to relay it without building a shield large enough to fully encompass the sender. Something that they would readily be aware of.

      This seems irrelevant though: provided two parties have some type of initial shared but not public knowledge, modern crypto can give you a reliably secure channel despite any number of intermediary parties.

    9. Re:Failsafe encryption requires no MitM by Electricity+Likes+Me · · Score: 1

      Actually, that's not correct. You do not need even one guaranteed interaction in order to establish an encrypted channel. Diffie-Hellman key exchange is pretty secure, as long as your encryption protocol is not broken.
      Whatever the circumstances, you need trusted endpoints, and you need a viable encryption protocol. You need those two. Not two out of a set of three, which include those. Untrusted endpoints means you're open to side channel attacks or simple bugging. Even if you have bulletproof protocols and 100% trusted interaction, it's no help if your endpoints have keyloggers sending their data to Eve.

      Diffie-Hellman just lets you establish session keys. It doesn't let you establish trust - you have no idea if the remote party is who you think they are, unless you communicate out-of-band or from a shared knowledge base.

      Trust establishment can be very simple and only needs to be done once if you protect your system, but it can't be done technologically - it's all about establishing a causal chain from someone else's brain to whatever the technology exposes.

    10. Re:Failsafe encryption requires no MitM by Anonymous Coward · · Score: 0

      What I say may be of little importance. Who I say it to I might want to keep secret.

    11. Re:Failsafe encryption requires no MitM by MrNaz · · Score: 1

      Aah yes, you are correct from a trust point of view. However, from a trust point of view, how can you really ever be truly sure of whom you are talking? Impersonation is always a problem, and then there's the issue of double agents and infiltrators. Then there's the whole sci-fi aspect like in the movie Face Off.

      --
      I hate printers.
    12. Re:Failsafe encryption requires no MitM by medcalf · · Score: 1

      That depends. Say you have an encrypted protocol relaying through my site. If there is a key exchange at the beginning, I can intercept the key exchange and handle the keys for both ends, decrypting transmits from A, and reencrypting them to go to B, and vice versa. Only if you had a shared secret that had NEVER gone through any other channels that could be intercepted, and which you could then use to set up your encrypted channel, could you reasonably trust a system that routes through someone else's hardware. But that takes an outside-of-the-network connection to set up, and thus is useless in any kind of any-to-any communications network.

      --
      -- Two men say they're Jesus. One of them must be wrong. - Dire Straits
    13. Re:Failsafe encryption requires no MitM by Hatta · · Score: 1

      This is what key signatures are for.

      --
      Give me Classic Slashdot or give me death!
    14. Re:Failsafe encryption requires no MitM by mark-t · · Score: 1

      It can often be the case that the actual content of the data is more important than who it is going to... presumably, if the data should go to the wrong party, it will lack sufficient context to be useful to anyone but whom it was intended for.

    15. Re:Failsafe encryption requires no MitM by Anonymous Coward · · Score: 0

      You can be pretty sure, if you are standing next to them that first time, for instance. In person impersonation begins to get into the "how can you be sure that the world exists?" realm. But, true enough, beyond "Cogito, ergo sum" very little can be known for certain.

    16. Re:Failsafe encryption requires no MitM by Electricity+Likes+Me · · Score: 1

      But this is true of all encrypted mechanisms and is the nature of establishing trust. There's no technological solution for it, other then to have actually met or otherwise established that who you are talking to holds a certain shared secret.

      The idea that "direct point to point" channels fixes it is foolish - without a shared secret, you can't be sure the channel is point to point to who you think it is, and the trouble and effort to establish it is is just a very convoluted way of establishing a shared secret.

    17. Re:Failsafe encryption requires no MitM by Electricity+Likes+Me · · Score: 1

      Aah yes, you are correct from a trust point of view. However, from a trust point of view, how can you really ever be truly sure of whom you are talking? Impersonation is always a problem, and then there's the issue of double agents and infiltrators. Then there's the whole sci-fi aspect like in the movie Face Off.

      Which it's worth noting, was resolved in that movie the same way - by using the common body of shared secrets to establish who was who.

      The only way to improve it would be to use the Socialist Millionaire means to allow them to establish that they have a shared secret without divulging what it is.

    18. Re:Failsafe encryption requires no MitM by mark-t · · Score: 2

      You don't need any previously shared secret to exchange data on an encryted communication path.

      For example.... both A and B can independently choose their own commutative key pairs (such as RSA) for a communication. The intent is for these keys to be disposable, so they do not need to be kept in any long term storage, nor does either party need to inform the other of either of its keys. The keys must be commutative in that they could be applied in any order, and one half of each pair will decrypt whatever was encrypted by the other half.

      A can randomly chooses something to be the starting point of a one-time hash for an upcoming secure communication, encrypts this data with one of its keys, and sends it. Since it is encrypted by one of the keys that A picked, and nobody else without physical access to A has any way to predict what keys it would have picked, this transmission from A to B is completely undecipherable by an eavesdropper. B then further encrypts the data with own of its own keys, and sends it back to A, so the data is different, but still encrypted. A now applies its second key to the new data stream and sends that back to B. It's worth noting that although both of A's keys have been applied, which would by themselves produce unencrypted data, one of B's keys has played a role in the value it now has, and so it will still be encrypted. It's worth noting that an eavesdropper who has been recording the conversation to this point may have enough data now to *potentially* start trying to decrypt the upcoming conversation, but the challenge of doing so with key pairs like RSA is NP-hard, and if the keys selected are wide enough, it will be completely impractical to do so... and even then, it still won't be generally achievable in real time (with a notable exception made for quantum computers, but nobody has yet demonstrated a completely scalable implementation of one that could eventually be applied to wide key encryption technologies). Finally, B decrypts the data on its own end, and can see the data that A had originally encrypted. A and B can now engage in a secure conversation using the secret data string that A selected.

      Of course, this is highly vulnerable to MitM attacks, but for unrouted communications such as point-to-point radio, you can't readily act as an MitM, since any communication you pick up with your own antenna will also be continuing on past you and be picked up by the intended recipient before you would be able to try to forge any data and send it on. You would have to try to block the entire signal, which isn't going to be practical for broadcast radio signals. And if you were to try to do this anyways, you would create interference in the communication, and this would be instantly detectable by the listening party.

    19. Re:Failsafe encryption requires no MitM by mark-t · · Score: 1

      There are, believe it or not, times when you are much more concerned with keeping data from being eavesdropped on far more than you are concerned with who you're sending it to because, presumably, the identity of the recipient has already been confirmed to your satisfaction by some other process.

      For example.... two people are communicating via ordinary radio. They exchange some discourse, and then determine that they must secure their communications with encryption to discuss more confidential matters. One party initiates a secure communication signal on the channel, and once the handshaking protocol is finished, they can engage in a completely encrypted communication on a channel that anyone could potentially eavesdrop on, but nobody would be able to comprehend the conversation, even if they had been eavesdropping from the beginning because of the nature of the protocol.

    20. Re:Failsafe encryption requires no MitM by gnoshi · · Score: 1

      Yeah, the 'two three' was a typo. I started with two, added the 'not broken protocol' to make it three, and screwed up my correction. But as other commenters have noted, without the one guaranteed secure interaction trust isn't established.

      With digital signing of keys by other trusted parties, this problem can be reduced but for 'failsafe' encryption you probably don't want to trust any third parties.

    21. Re:Failsafe encryption requires no MitM by pantaril · · Score: 1

      Only if you had a shared secret that had NEVER gone through any other channels that could be intercepted, and which you could then use to set up your encrypted channel, could you reasonably trust a system that routes through someone else's hardware. But that takes an outside-of-the-network connection to set up, and thus is useless in any kind of any-to-any communications network.

      Why do you think it's useless? I think it's much better than using no ecryption at all. You can either exchange the secret by other channel (personaly for example) or you can exchange the key before the channel is intercepted (i.e. before you start doing anything suspicious or illegal)

    22. Re:Failsafe encryption requires no MitM by medcalf · · Score: 1

      Useless for any-to-any communication, I said. Because any-to-any implies that there is no other channel.

      --
      -- Two men say they're Jesus. One of them must be wrong. - Dire Straits
  10. Maybe try it on an iPod Touch rather than a phone by Elwood+P+Dowd · · Score: 1

    Even if Silent Circle is secure, that doesn't mean that the cell phone is secure. The safest mobile innernet device is probably an iPod Touch.

    --

    There are no trails. There are no trees out here.
  11. Much easier ways by SuperKendall · · Score: 1

    Wouldn't they just mandate that your provider give them access to your device to record anything going to your mic?

    Why all the high-tech twists when if they really cared they'd just bug the rooms in the places you hung out in most often?

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Much easier ways by wirefall · · Score: 1

      Because I can turn on a million mics with a touch of a button...wireless warrant taps for undesirables. Requesting a million warrants and placing a million bugs...do the math. But I agree, a covert camera to record you typing your password is infinitely easier than breaking your PGP key.

    2. Re:Much easier ways by AHuxley · · Score: 4, Interesting

      The phone gives you movement, address books, links to others, the home computer - its everything any LEO has wanted over the electronic generation -
      A beacon, trap and trace, a microphone, a camera lab (as in pictures taken, shared, gps, unique data in every image to find other images you took and posted)...
      As for any encryption - detailed keystroke logs, clear-text captures of passwords was offered by diagnostic options shipped in many US telco offerings.
      You had the 'mic on' remote dial in, spyware in the cell phone infrastructure - when will a generation learn to put down their small versions of ENIGMA?
      As for 'your device to record anything going to your mic? "
      The classic case was the NSA and GCHQ - let us work in the dark and we can predict the future ... federal political leaders get a heads up on terms of interest from around the world.
      Then you had federal police asking for non court help with encryption, tracking...
      Then for logs, recordings ... then for closed court voice recordings..
      Then high profile cases... state task forces.. fusion centers... the press reports on recordings ...
      At some point the court magic stops and that next person of interest takes the battery out.

      --
      Domestic spying is now "Benign Information Gathering"
    3. Re:Much easier ways by wirefall · · Score: 1

      That's why @AHuxley we should all be yelling "bomb, bomb, president" into our phones at all times....

    4. Re:Much easier ways by Dr_Barnowl · · Score: 2

      In innocent ways as well..

      "Yo yo, man, this President butter is the BOMB man, it's so beautiful, like yellow cake. Margarine is just toxic, it gives me food poisoning. Those trans-fats are a public health issue. I swear, it gives me the runs like salmonella, a real brown out in my pants. I'm in the facility, performing evacuation of my bowels until there's a spillover. Dropping a real dirty bomb, you know what I'm saying?"

      (selected words from this list

    5. Re:Much easier ways by Anonymous Coward · · Score: 0

      I'm not sure that qualifies for every definition of the word 'innocent'...

  12. Re:App store approved? by tlhIngan · · Score: 3, Insightful

    I doubt it. Our apple overlords will categorise this as 'Undesirable' as it allows their phone users to communicate in ways that they want, and not in ways that are overlord approved.

    Given iOS has no APIs for making phone calls without involving the dialler or sending SMSes without invoking Messages, this app would have to be entirely self-contained. Effectively, it's a VoIP phone app that does SMS and MMS, just offering strong encryption.

    And there are plenty of VoIP phone apps on iOS. As are private network "free" texting type apps. This is nothing special other than offering encryption.

    So in the end, it's just another VoIP app, or "free texting" app, of which there are tons. Like say, Skype.

  13. problems with America? by Anonymous Coward · · Score: 1

    "off-shore"?
    Are the people starting to realize that the enemy is within?

  14. so excited. by ctime · · Score: 5, Insightful

    "Neal Ungerleider notes that cryptography pioneer and Pretty Good Privacy (PGP) creator Phil Zimmermann has launched a new startup that provides the illusion of industrial-strength encryption for Android and iOS where users will have access to encrypted phone calls, emails, VoIP videoconferencing, SMS, and MMS.

    There, fixed it for you.

    Does anyone really think any application that is layered on top of IOS is free from interception? Everything is an API, all hidden away, and as much as I love Apple, there is no way in hell I would trust any application running on that device to be free from covert interception(keyboard, voice, you name it). I'm not saying that app doesn't encrypt and do all the right things when transmitting over a network, but I'm going to assume everything is compromised locally on the phone.

    And not to be a tin foil hatter, but really, who pays for this stuff and paid these guys salaries in the past anyways (hint, it was your famous uncle).

    1. Re:so excited. by Magada · · Score: 1

      Does anyone really think any application that is layered on top of IOS is free from interception?

      I, for one, don't.

      One other point of contention - the system is based on existing public key crypto. Therefore all messages exchanged are non-repudiable by design.

      --
      Something bad is coming when people are suddenly anxious to tell the truth.
    2. Re:so excited. by Anonymous Coward · · Score: 0

      By your logic nothing running on top of any OS can be trusted, therefore why bother encrypting anything?

    3. Re:so excited. by Zero__Kelvin · · Score: 1

      "And not to be a tin foil hatter, but really, who pays for this stuff and paid these guys salaries in the past anyways (hint, it was your famous uncle)."

      You sound exactly like a tin foil hatter, actually. Are you saying that Phil Zimmerman is now, or has been, working for the US Government?

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    4. Re:so excited. by HPHatecraft · · Score: 1

      agreed. having an industrial strength lock doesn't matter if it is mounted on a door to a building made of 1/4" thick plywood. For all that, sometimes 1/4" thick plywood is just enough of a barrier. But, for what you are thinking of, anyone with the will will not be deterred.

    5. Re:so excited. by Anonymous Coward · · Score: 0

      It's the backdoor you should worry about, silly :)

    6. Re:so excited. by Anonymous Coward · · Score: 0

      Does anyone really think any application that is layered on top of Android is free from interception?

      Seriously, Google has a much bigger incentive to break this encryption than Apple does, considering their entire business model is based on data mining.

      Personally, I know enough about encryption to know that it isn't exactly easy for an OS to intercept encrypted communications from inside a running application. What is it going to do, scan the entire memory region for what looks like a private key before the handshake is complete so the symmetric key can be derived? Apple or Google would have to reverse engineer the app first, then push out an OS update to break the encryption on something like this.

  15. Both Good Guys and Bad Guys Will Find it Useful by qbitslayer · · Score: 1

    If rebels fighting for a good cause can use this to their advantage, so can the terrorists.

    I wish I lived in a world where there were no need to encrypt anything.

  16. Re:IT'S A TRAP! If it is not P2P, it is NOT secure by Anonymous Coward · · Score: 1

    How are you going to handle NAT traversal without a central server? Read up on the ZTRP protocol. The server is just a dumb relay, passing encrypted bits back and forth. The keys live on the devices, so the server couldn't decrypt the data even if it wanted to.

  17. Does it encrypt REAL phone calls? by gnoshi · · Score: 4, Interesting

    While it is nice for someone to be making an easy-to-use all-in-one encryption app, the real question for me is this:
    Does it encrypt phone calls; real, phone-to-phone, no-VoIP phone calls.

    There are already several solutions out there for encrypted VoIP. Even a free, open-source general-purpose Android SIP client CSipSimple supports ZRTP for key exchange (or 'of course' a free, open-source ...)
    However, I have not found a single app (and indeed only a few specialised devices) to actually make encrypted phone calls without using VoIP, and none that have made encrypted phone calls over GSM voice. A few people have talked about phone call encryption over GSM voice (e.g. at DEFCON) and there are many papers on the topic of data-over-GSM-voice), but I haven't yet seen it implemented. If this *does* implement it, *then* I'll be pumped.

    On the SMS front, there is already TextSecure for sending encrypted SMS, and all the key exchange is handled through SMS (and perhaps MMS? I believe only SMS). Mind you, Moxie Marlinspike hasn't released the source for it (and it is now owned by Twitter, so we'll probably never see it).

    1. Re:Does it encrypt REAL phone calls? by gnoshi · · Score: 1

      And then I RTFPM (PM = promotional material) and it doesn't encrypt phone calls, SMS or MMS. It provides yet another encrypted VoIP and Email-Replacement-Over-IP. On the upside, it is actually encrypted and appears to use keys which are stored by the endpoints and not in the middle, so it is no less secure than using x509 or (G)PG(P) encryption for e-mail, or SRTP for calls.

      I guess it might provide an easy solution for key exchange. That would be a win.

    2. Re:Does it encrypt REAL phone calls? by gweihir · · Score: 1

      You do understand that there are basically no non-VoIP systems today, do you? Even GSM typically goes to VoIP somewhere in the chain, sometimes right at the base-station. No, they may not want to admit that and often it is at least with reserved bandwidth and good synchronization which ordinary VoIP lacks. But basically there is nothing special about GSM anymore.

      On the angle of existing applications, when PGP came out, there were a lot of encryption programs, and all sucked and/or were expensive commercial products. There is indication that what is currently available for Android SIP is not very good. Remember that Zimmermann now had quite a while to observe how his most widely used product so far (and its users) survived in the wild. That is a bit different from the toys and feel-good products you reference. Of course, he could mess up this time. But nobody in the civilian market has this kind of experience and level of insight and I doubt anybody in the non-civilian market is any better.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:Does it encrypt REAL phone calls? by gnoshi · · Score: 2

      You're missing my point about encryption over GSM voice, and encrypted SMS, which is that neither GSM voice nor SMS require a GPRS/3G/4G/WiFi connection.
      I don't care whether things are VoIPed left, right and centre once it's hit the tower, but between my phone and the tower GSM and SMS has advantages.

    4. Re:Does it encrypt REAL phone calls? by gweihir · · Score: 1

      You're missing my point about encryption over GSM voice, and encrypted SMS, which is that neither GSM voice nor SMS require a GPRS/3G/4G/WiFi connection.
      I don't care whether things are VoIPed left, right and centre once it's hit the tower, but between my phone and the tower GSM and SMS has advantages.

      I highly doubt that. GSM codecs are so much worse that what is available today. As to SMS, just make your Emails shorter and you get the same. Or rather much better as the SMS backend sucks.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    5. Re:Does it encrypt REAL phone calls? by gnoshi · · Score: 1

      Just to clarify: You highly doubt that a GSM voice call and SMS don't require a GPRS/3G/4G/WiFi connection? Really?
      I think you may be a little bit confused. Or stupid. It could be either.

    6. Re:Does it encrypt REAL phone calls? by gweihir · · Score: 1

      Thanks, and same to you, regarding "stupid" and "confused". Maybe I meant that GSM does not have advantages between your phone and the tower? But seeing that would require actual reading comprehension. Seems you do not have that. And maybe you are out of touch with current technology?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    7. Re:Does it encrypt REAL phone calls? by Ash-Fox · · Score: 1

      I have been waiting on Whispersys to update for a while now. All they've done is remove their downloads instead. I am not impressed. That's not really "out there".

      --
      Change is certain; progress is not obligatory.
    8. Re:Does it encrypt REAL phone calls? by Anonymous Coward · · Score: 0

      Um, the source has been released for months. They are both still actively developed.

      https://github.com/WhisperSystems/TextSecure
      https://github.com/WhisperSystems/RedPhone

      Server side source for RedPhone is incoming..

    9. Re:Does it encrypt REAL phone calls? by gnoshi · · Score: 1

      Yeah, my comment was unduly harsh and I regretted posting it shortly after I had: I shouldn't be attributing to stupidity what I could attribute to misunderstanding.

      Anyway, my whole point was that GSM voice *does* have an advantage between your phone and the tower, and until GPRS/3G/4G provide the same QoS and coverage as GSM voice calls it will continue to have an advantage. There may be situations in which you can't make GSM voice calls but can get GPRS/3G/4G, but it is much more likely you will be in a situtation where you can't use GPRS/3G/4G but are able to make GSM voice calls. You seem to be claiming that isn't the case. I'm claiming that you're wrong.

      Such a claim isn't being out of touch with current technology. It is acknowledging that voice calls and SMS on mobile networks will continue to work even when mobile IP connectivity is choking.

    10. Re:Does it encrypt REAL phone calls? by gnoshi · · Score: 1

      That's fantastic - I somehow overlooked that. Next on the 'want/I should do myself' list: integrating that into CyanogenMod so it can send encrypted SMS transparently.

    11. Re:Does it encrypt REAL phone calls? by Anonymous Coward · · Score: 0

      No one listens to you here. We're not impressed by those as stupid as yourself.

  18. The Serval Project by complete+loony · · Score: 1

    So similar to the set of services that the Serval Project (my current employer) is aiming to deliver? But it costs $20 a month, and it only works when you have a viable internet connection to their servers?

    When the Serval product set grows to include an internet directory service, I'm certain we'll be able to run it for less than $20 a month. Probably for less than $20 a year.

    --
    09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    1. Re:The Serval Project by gnoshi · · Score: 1

      Or maybe not even vaguely like Serval, since rather than being a distributed mesh network Silent Circle is an encryption communication platform.
      Don't get me wrong, I think it is a great project and I'm very happy to see it appearing - I've been hoping something your project would appear for ages. It is just almost, but not quite, entirely unlike the product in TFA.

    2. Re:The Serval Project by complete+loony · · Score: 2

      No it really is. Serval is building an encrypted, *decentralised* communication platform, that can also route packets over a local mesh network. Initially including voice, text, and file transfer services. But that doesn't mean we are forever limited to only supporting communications over a local mesh, or that we will be limited to this set of secure services. Just that providing communications in an emergency, without supporting infrastructure, is our main focus. Everything must always work in isolation.

      I've already experimented with a prototype internet directory service, combined with a packet relay service that could provide Serval to Serval internet calling right now. Implementing it was fairly easy. But we really need to use a Distributed Hash Table for scalability, and provide a separate STUN-like 2-way NAT traversal service to punch direct p2p paths through the internet. Then we won't need to provide much supporting infrastructure at all. Since these services would be run by the very people using the network, I'm not even sure what service we could justify charging for. Except perhaps for terminating calls to the PSTN, which is also a capability we've already built.

      Basically I'm saying that with only a couple of months of dedicated effort (and funding....) we could be providing the exact same service as Silent Circle for a fraction of the cost. Though we only have an android client right now, we test our back end daemon on linux & OSX and could start building a desktop front end.

      We're getting close to releasing an alpha version of 0.90. This represents a major leap forward under the hood from the current 0.08 version available on the android market. 0.08 is a collection of loosely related applications held together with string and sticky tape; BATMAN, asterisk, wifi-tether, dna & SipDroid. For 0.90 we've rebuilt the core of our solution from the ground up and thrown away the pieces that never really fit together that well in the first place. We're not ready to call it version 1.0. There's still a lot to do before we reach that point, but 0.90 is a *lot* closer to where we wanted to be.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    3. Re:The Serval Project by Herve5 · · Score: 1

      I'm definitely interested into this, heard of Serval before -probably here-, but when going to your site I definitely don't find how I could register, be it for $20/month, nor even am I capable to find if my current devices (Nokia N9000, Blackberry playbook, macintoshes...) indeed have applications available.
      Please see no offense, definitely, but if I'm wrong do show me where to go!
      (or then get a "register your email to be warned when..." button on page 1 of the site?)
      H.

      --
      Herve S.
    4. Re:The Serval Project by complete+loony · · Score: 1
      Android only for the moment. Though we haven't actively tried to promote the application, there have been burst of new users after a few minor announcements or other media attention.

      You could sign up to our developer email list, I don't think we have a low traffic announcements list.

      Anyone who wants to use our daemon as the basis of a port to other platforms is welcome to start one. We've also got an asterisk channel driver, if you'd like to use any other voice protocol like SIP to talk to other Serval phones or use Serval phones as extensions in an office PBX. But I wouldn't call either of those options polished.

      I think the project has a lot of potential. We've invested a lot of time in the last year building our basic set of services to a demonstrable state. Though there's always something else that could be improved.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    5. Re:The Serval Project by gnoshi · · Score: 1

      No it really is. Serval is building an encrypted, *decentralised* communication platform, that can also route packets over a local mesh network.

      Ok, cool. When I looked over the website I saw a lot of discussion of mesh, but not discussion of encryption. I'll have more of a look.

  19. He is still active? Nice! by gweihir · · Score: 2

    The PGP documentation files were the first hands-on documentation for encryption I read that actually got it right. They are still among the few today. Most texts either get the crypto wrong or the environment or the procedures on how to use the thing. These did not.

    Of course, PGP went through some refactoring and design changes, but the basic code was sound. If he manages to achieve this with this new product, it will be the only one on the market that this can be said for. Basically all others are buggy, badly designed, insecure because of fundamental misunderstandings or easy to make user errors, etc. Of course, careful review is still required, but this product should be worth the effort.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:He is still active? Nice! by Anonymous Coward · · Score: 0

      Maybe back then but not now. The OpenPGP specification is outdated. It still specifies PKCS#1.5 for RSA padding. This is known to be extremely weak yet the specification still requires it in 2012. Better would be OAEP or PSS, but it takes these standard bodies forever and a day to change. We should all be using ECC by now, but that looks to be years off, even though the technology has been available for years.

  20. Frying ears by tsa · · Score: 1

    Reading the title I thought this was about some quack who made an app that 'prevents' you from the electromagnetic radiation while calling. Then I read the blurb and I thought: what has this to do with encryption? Then I saw that the title said Prying ears, not Frying ears. Aha!

    --

    -- Cheers!

    1. Re:Frying ears by Anne_Nonymous · · Score: 1

      >> I thought this was about some quack

      Bob Dylan is not a quack.

  21. Only during trust establishment! by jhantin · · Score: 2

    Protocols can be devised in such systems which are completely eavesdrop tolerant, such that even if eavesdropping did occur, it would be indecipherable, even if one were to try to listen to the entire communication, including the protocol setup itself, it would sound like undecipherable gibberish right from the moment that the encryption began.

    Such protocols can be vulnerable to MitM attacks, but that is why they are really only reliable as encryption when the communication is not subjected to any routing.

    The criteria you give are accurate for key agreement in the absence of a preexisting trust anchor, such as the classic Diffie-Hellman key exchange protocol. However, once a trust anchor is established — for example, by meeting and agreeing on a shared secret or verifying one another's public keys in person — that shared secret or known-good public key can be used for authenticating or verifying digital signatures on messages that arrive over an untrusted communication path.

    --
    ...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
    1. Re:Only during trust establishment! by Anonymous Coward · · Score: 0

      The moderators must be asleep tonight. Grandparent is a troll, and the parent sets him straight.

  22. You betray yourself by Anonymous Coward · · Score: 5, Insightful

    "There's already a ton of precedent for Apple to approve something like"

    "ton of precedent"
    and
    "something like"

    Really give away your lack of confidence in your own argument. Let me state something so you can see the difference.

    "The application WILL be approved for sale on Android, that is inevitable as day follows night."

    There, and that's why Apple will ultimately fail. Because even the fanboys don't have confidence in Apple making the decision they think is right.

    1. Re:You betray yourself by interkin3tic · · Score: 1, Offtopic

      And this, children, is why creationists stand any ground against evolutionary theory: because some people take a reasonable unwillingness to overstate their point as being uncertain about their argument.

  23. Target markets? by Anonymous Coward · · Score: 0

    "For encryption tools, which are frequently used by dissidents living under repressive regimes..."

    So are the UK and the US established, or emerging markets?

  24. Pointless by aaaaaaargh! · · Score: 3, Insightful

    The company is US-based. No matter how renowned the makers of this software are, under the Patriot Act they can be forced to secretely put backdoors into their apps and never tell anyone. For this reason alone the encryption is worthless, and possibly even dangerous for companies outside the USA that have to guard trade secrets.

    1. Re:Pointless by Anonymous Coward · · Score: 1

      Their servers are in Canada....

    2. Re:Pointless by sociocapitalist · · Score: 1

      The company is US-based. No matter how renowned the makers of this software are, under the Patriot Act they can be forced to secretely put backdoors into their apps and never tell anyone. For this reason alone the encryption is worthless, and possibly even dangerous for companies outside the USA that have to guard trade secrets.

      I wouldn't say it's worthless but yes, governments have to be taken into account such as India forcing blackberry to give them the blackberry encryption keys.
      http://www.theregister.co.uk/2012/08/02/rim_keys_india/

      But it's not worthless because you're still protected from most potential listeners, just not all of them.

      --
      blindly antisocialist = antisocial
  25. What's wrong with Gmail? by hcs_$reboot · · Score: 1
    From TFS

    They're not using secure email. They're using Gmail to send PDFs.

    Isn't Gmail using SSL to send and receive mail? Isn't that secure enough?

    --
    Slashdot, fix the reply notifications... You won't get away with it...
    1. Re:What's wrong with Gmail? by blake1 · · Score: 2

      I didn't read TFA, let alone finish reading TFS, but what you're suggesting is that securing the message in transit between the client and server is sufficient security. What about between the client and another client (SMTP)? Or when the bits are sitting idle on Google's spindles (read: being indexed and monetised)?

      The problem I have with this type of solution is that we are placing absolute trust in the vendor's promises that it won't snoop on our data. If I personally generated my CSR and kept my keys secure and in a known location then I would have a little more faith, but unless they open source this and allow me to maintain my own back-end infrastructure I would be more concerned about sending my confidential information using this solution than not - as it's effectively a choke-point for all things sinister and you can bet your last $20/month that the authorities have all they need to intercept your data. After all, and I'm assuming the service is hosted in the US, the White House has access to any keys which are transmitted to and from Silent Circle's systems.

      There was another app touted as having military-grade privacy recently, the free-to-install Wickr for iOS. I contacted them after downloading the application in June to pose the question of just what level of trust they expected me to place in their application and infrastructure, to which they promptly responded that their code was under review and they would update their FAQ over the subsequent days. I've just checked and can't even see a FAQ on their website.

    2. Re:What's wrong with Gmail? by blake1 · · Score: 1

      Oh, and not to mention that there is no doubt your handy iCloud backups which are conveniently located on Apple's very own servers will contain a readily available copy of any keys stored within your app's document space, just waiting for the first person who rolls through their doors warrant-in-hand.

    3. Re:What's wrong with Gmail? by bWareiWare.co.uk · · Score: 1

      No. Not sure what more the is to say. All it takes is one certificate authority caring more about a government contract then your privacy, or just any one of thousands of people at different stages of the chain making a mistake.

    4. Re:What's wrong with Gmail? by mike10027 · · Score: 1

      I didn't read TFA, let alone finish reading TFS... After all, and I'm assuming the service is hosted in the US, the White House has access to any keys which are transmitted to and from Silent Circle's systems.

      From TFA: "Silent Circle stresses that their product offers secure communications within the networks and only uses Canadian servers that are outside of U.S. government control."

  26. Secure Communications? by clonehappy · · Score: 1

    On Android or iOS?

    I don't think people understand the definition of secure, then. Before you start worrying about your messages being secure after they leave the device, you should be concerned with the security of the device itself. It's pretty widely accepted by those in the know that Android and iOS are effectively trojans (and/or can easily be compromised if you still believe the OS itself is secure) for spooks of all sorts. If a message absolutely, positively has to be secure, it should never touch a device capable of connecting to an "internet" of any kind.

  27. they're what?? by xushi · · Score: 1

    ".....They're in a hotel in the Middle East"

    That's plain stereotypical and frankly quite offending.. The "Middle East" - which mind you consists of several countries cultures and races - is not all bad, and certainly this case can be applied to any country, and many hotels in all them countries.

    1. Re:they're what?? by Zero__Kelvin · · Score: 1

      So you think these people are trying the help the people in the Middle East secure their communications because they don't like them. Where did you get the idea that the fictional someone in the Middle East was being called "bad"?

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  28. Huh? by Anonymous Coward · · Score: 0

    Since when did the carriers start allowing the core voice stream to be altered? AFAIK, every single carrier prevents smartphone manufacturers from being able to access that part of the phone's functionality (they can initiate calls etc but cannot muck with the actual data)

  29. Copy NSA by Anonymous Coward · · Score: 0

    NSA has approved an Android phone for use by government officials to make TOP SECRET calls. link: http://www.theverge.com/2012/3/2/2838729/nsa-project-fishbowl-secure-android-devices-network

    It is doubly encrypted with the VOIP server sitting inside Ft. Meade (where the second level of crypto gets added). So, if NSA is doing this, then it is fully possible to get secure calls over traditional cell networks. Of course, they have access to all the hardware and have made modifications there as well. And, of course, their server in Ft. Meade won't be usable by us mere mortals (nor will their encryption algorithms which are Type I classified algorithms).

  30. They're actually offshore by Anonymous Coward · · Score: 1

    As mentionned on their website.

    1. Re:They're actually offshore by Anonymous Coward · · Score: 0

      That's fairly irrelevant since the company headquarter is in the US and the company's founders and their lead technical personnel are US citizens. If they receive an NSL with a gag order, they'll have to comply no matter where the servers are located (or, never ever set a foot onto US soil again).

    2. Re:They're actually offshore by undeadbill · · Score: 1

      It's a shame the comment was modded down. AC's statement is inline with CISPA and the Patriot Act as they are applied in the United States. Nick Merrill, founder of the Calyx Institute, was the ONLY person running an ISP to turn down one of those orders to snoop on his customers and fight it in court. Ever. The only other people who have fought National Security letters in court were librarians. Considering that orders for disclosure under National Security letters are in the tens of thousands, and each letter can apply to hundreds or thousands of records, I would say that the AC has good reasons for their concern over where this project is based out of. This is also why OpenBSD won't let US citizens work on key project internals either.

      I like Phil Zimmerman's work, but basing his product out of the US as a US citizen means that his system can and will be used for MitM attacks against his users. His website is clearly marketing this tool for DoD use, as a GSA contract could pretty much secure his or anyone else's future. I don't blame him for doing that, as there is a sizable market for this within the US and for US business travellers abroad- for private business use. For anyone with ANY political involvement within or related to the US or US policy, my thought is ymmv.

  31. Failing? Make crypto easier. by DulcetTone · · Score: 1

    I have found in my own limited use of cryptography code that I was entirely unsure if I were using it correctly or as intended, owing to a completely new lingo used for everything, which was nowhere bound to a comprehensive explanation of what it meant, why it was needed, and what practices should be avoided.

    I came off thinking the big advance would be to avoid sending out under-documented code in the first place. The average user is not a cryptologist, but a vanilla coder-of-things, and to avoid heartache at the user level, these coders must find the libraries straightforward.

    --
    tone
  32. Bull by LeadSongDog · · Score: 1

    Show us where P.Z. ever said this would be "completely secure". Such a claim is the hallmark of snake oil, as described at http://www.philzimmermann.com/EN/essays/SnakeOil.html

    --
    Oh, I'm sorry sir, I thought you were referring to me, Mr. Wensleydale.
  33. Examples? by SuperKendall · · Score: 1

    And how many seemingly innocuous apps are denied, when we would predict they should be fine?

    None that I know of. I provided a link with an example, funny you cannot do the same.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Examples? by Jessified · · Score: 1

      You sure are snarky for someone who is seemingly incapable of using a search engine.

      Google: "site:techdirt.com apple arbitrary" They've done a fairly thorough job of documenting Apple's arbitrary policies. Of course, Apple is free to be as arbitrary as they wish, as are the fanboys free to defend them blindly (thanks for your shining example!). And the rest of us are free to criticize their silly approach and enjoy a superior product.

      For the lazy ones:
      http://downloadsquad.switched.com/2009/04/24/crudebox-becomes-prudebox-to-make-it-into-the-app-store/
      http://almerica.blogspot.ca/2008/09/podcaster-rejeceted-because-it.html
      http://news.cnet.com/8301-17939_109-10042127-2.html?part=rss&subj=news&tag=2547-1_3-0-20
      http://forum.nin.com/bb/read.php?59,651569
      http://www.escapistmagazine.com/news/view/91508-Apple-Blocks-Obscene-Newsreader-App
      http://www.guardian.co.uk/technology/blog/2009/may/21/apple-iphone
      http://www.wired.com/gadgetlab/2008/09/apple-imposes-n/
      http://www.gamasutra.com/view/news/36946/Interview_Molleindustria_On_Phone_Storys_Objectionable_Message.php

      I await your apology with bated breath.

  34. And also iOS by SuperKendall · · Score: 1

    "The application WILL be approved for sale on Android, that is inevitable as day follows night."

    And also on iOS. I just have to help people understand why it is so certain, because people like you like to raise doubts where none rightfully exist.

    Since Google has also pulled apps from the Android app store, you have no greater certainly that it will stay than on iOS.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  35. Vaporware or cutting edge research? by Anonymous Coward · · Score: 0

    Presumably the one-to-one voice calls will use ZRTP for end to end encryption. How will they support end-to-end encryption (which is the assumption here) for multi-party voice and video conferences?

    Last I checked, *useable* multi-party video/voice requires heavy muxing server side, moreover, last I checked, homomorphic encryption isn't quite up to the task of RT audio/video processing.

    So, really, aisde from some generic OTR and ZRTP wrapped in a turn-key bundle, their conference solution will be competing with Skype, Google Hangout, Netmeeting, Cisco Telepresence, WebEx, etc.

      Unless of course he has some futuristic science up his sleeve.
       

  36. Bad examples, all wrong. by SuperKendall · · Score: 1

    Google: "site:techdirt.com apple arbitrary"

    Well you could do that if you wanted to end up with a lot of out of date and incorrect information. But that's close enough for an Apple Hater!!

    http://downloadsquad.switched.com/2009/04/24/crudebox-becomes-prudebox-to-make-it-into-the-app-store/

    The link even says it's in the App Store. Next!

    http://almerica.blogspot.ca/2008/09/podcaster-rejeceted-because-it.html
    http://news.cnet.com/8301-17939_109-10042127-2.html?part=rss&subj=news&tag=2547-1_3-0-20

    Podcaster is in the App Store.

    http://forum.nin.com/bb/read.php?59,651569
    http://www.escapistmagazine.com/news/view/91508-Apple-Blocks-Obscene-Newsreader-Apphttp://www.escapistmagazine.com/news/view/91508-Apple-Blocks-Obscene-Newsreader-App

    Apple is very clear they do not allow obscene/pornographic content in the app store (this is not an arbitrary rule):
    "Applications must not contain any obscene, pornographic, offensive or defamatory content "

    http://www.guardian.co.uk/technology/blog/2009/may/21/apple-iphone

    Apple is in fact Allowing Kama Sutra on the app store.

    http://www.wired.com/gadgetlab/2008/09/apple-imposes-n/

    This article was not correct even way back in 2008 when it was posted.

    http://www.gamasutra.com/view/news/36946/Interview_Molleindustria_On_Phone_Storys_Objectionable_Message.php

    Prohibiting child abuse in an app is not an "arbitrary" policy.

    SInce you can't even be arsed to check a lint you copy from Google, I see no reason to read anything further from you or to respond again. As such you may have the last most and copy blindly from Google all the outdated links you like.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  37. Easy to use versus security. by Anonymous Coward · · Score: 0

    In this kind of product, the only way to have Easy to use with security if you trust in your server, because security need steps not used by open communications.
    For example, the most common problem we have is the user authentication, that if not well implemented, will let the man-in-the-middle attack.
    Skype has a good security when the client communicates with the server, but in the server the privacy is broken.

    If your client uses RSA for authentication, we will need a protocol to secure the keys, very complicated for beginners.
    I think in this case the easy to use is you trusting in the provider, but this "Easy to use" will allow the provider break your security.

    For these reasons, I designed a secure voice encryption product to be launched for android next month that is "Easy to Use", but will deploy an option for our clients acquiring and configuring their servers, and each server will be under control of our users. All authentication keys are generated by our clients.
    This is the only way we can deploy a good product with ecurity and "Easy to use".
    Next month you will be able to download it in Android Market.