[messaging] EFF Secure Messaging Scorecard
contact at taoeffect.com
Thu Nov 6 08:48:43 PST 2014
On Nov 6, 2014, at 8:39 AM, Tyler Manson <tyler at hack.ink> wrote:
> Okay, I'm confused. I've been following the back-and-forth on twitter
> here: https://twitter.com/ncardozo/status/530392765771698176
Odd, when I click that link, twitter does not show me my replies, only Nate's replies to me.
If I click this link (the start of the thread), however, it does show me everyone's replies:
> Seems pretty End to End to me....
It is not end-to-end. If you've been following the twitter, you should have seen the explanation as well:
@taoeffect: I read the iMessages section from the 2014 paper. It is no different than is described: http://blog.quarkslab.com/imessage-privacy.html
@taoeffect: This remains true: "Apple can decrypt your data, if they want, or more probably if they are ordered to."
@taoeffect: Quarkslab feels in spite of that it is still “end-to-end”. W/e, I have a different definition of “end-to-end”.
@taoeffect: Apple’s claim on their website are FALSE. They *can* decrypt iMessages if forced.
@taoeffect: For me, “end-to-end” means Apple is incapable of decrypting messages. They are capable, so it’s not e2e.
@dangoodin001: That's precisely my definition of e2e, too!
Then there's the 2nd stake through Apple's claims where by default they appear to have access to plain text of this history of your chats (as has been linked to multiple times now in this thread):
Please do not email me anything that you are not comfortable also sharing with the NSA.
> How exactly is iMessage not secure end to end? According to page 34 of
> the white paper that @ncardozo posts:
> "the device generates two pairs of keys for use with the service: an
> RSA 1280-bit key for encryption and an ECDSA 256-bit key on the NIST
> P-256 curve for signing. The private keys for both key pairs are saved
> in the device’s keychain and the public keys are sent to Apple’s
> directory service (IDS)"
> "The public RSA encryption keys of the receiving devices are retrieved
> from IDS. For each receiving device, the sending device generates a
> random 128-bit key and encrypts the message with it using AES in CTR
> mode. This per-message AES key is encrypted using RSA-OAEP to the
> public key of the receiving device. The combination of the encrypted
> message text and the encrypted message key is then hashed with SHA-1,
> and the hash is signed with ECDSA using the sending device’s private
> signing key. The resulting messages, one for each receiving device,
> consist of the encrypted message text, the encrypted message key,
> and the sender’s digital signature. They are then dispatched to the
> APNs for delivery. Metadata, such as the timestamp and APNs routing
> information, is not encrypted. Communication with APNs is encrypted
> using a forward-secret TLS channel."
> "f the message text is too long, or if an attachment such as a photo is
> included, the attachment is encrypted using AES in CTR mode with a
> randomly generated 256-bit key and uploaded to iCloud. The AES key for
> the attachment, its URI (Uniform Resource Identifier), and a SHA-1
> hash of its encrypted form are then sent to the recipient as the
> contents of an iMessage"
> Seems pretty End to End to me.... Assuming that Apple doesn't collude
> with the NSA and backdoor the binary blob and the closed source parts of
> the OS, but that's a different attack vector...
> On 11/06/14, Mike Hearn wrote:
>> iMessages does not meet (1) as has been stated multiple times now
>> Alright, let me clarify my statement a little bit - iMessages meets (1)
>> assuming you decide to actually use it in that way, and I think it's reasonable
>> to assume that people understand "backing up my messages to Apple" means Apple
>> gets to read them. I'd be surprised if that caused real users any confusion.
>> I don't think an app should be dinged for not being fully end to end out of the
>> box, if you can make it so with a single tap.
>> Yes, that is true, but that is also orthogonal to what is being discussed
>> I don't agree, it seems fundamental rather than orthogonal. If resistance
>> against malicious providers giving you bogus software is a requirement to be
>> considered end to end then no such technology has ever been successfully
>> deployed, given the vanishingly tiny number of people who only use programs
>> they compiled themselves from audited source snapshots.
>> 2. Whether EFF is intentionally or unintentionally misleading their readers
>> when they say that Apple is (a) unable to read messages, and (b) keeps past
>> comms secure from the provider.
>> (Yes, I am convinced they are.)
>> Why? You haven't shown that. EFF assumes some modicum of understanding on the
>> behalf of the user, and under that assumption iMessages appears to be safe
>> against reading of past messages.
>> Messaging mailing list
>> Messaging at moderncrypto.org
> The preceding email was cryptographically signed to provide verification
> that I personally authored it, and that it was not modified in transit.
> Privacy in communications is a fundamental human right codified in
> Article 12 of The Universal Declaration of Human Rights. Organizations
> and individuals that participate in the mass surveillance of internet
> communications are committing crimes against humanity.
> In order to resist those that seek to abuse the powers of technology, as
> well as to explicitly establish an objective expectation of privacy, I
> strongly recommend the use of PGP encryption in all private dialogue
> between individuals, yourself and myself included. My public key
> fingerprint is published in the X-PGP-KEY header of this email, and is
> searchable at pgp.mit.edu.
> To learn about encrypting your own emails, go to
> This email signature, separate from the actual contents of the above
> email, is hereby published into the public domain. You may copy and
> attach it to your own correspondence at your will.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Messaging