If You Can’t Break Crypto, Break the Client: Recovery of Plaintext iMessage Data

Re:If You Can’t Break Crypto, Break the Client: Recovery of ... by duaneb on Friday April 08, 2016 @02:33PM (#11456823)

Given the breadth of ways to leak information about the private keys--side channel attacks, physical attacks, userspace (allocator, random number generator) this would be extremely difficult (impossible?) to prove.

[ Parent | on HN ]

Re:If You Can’t Break Crypto, Break the Client: Recovery of ... by stcredzero on Friday April 08, 2016 @02:49PM (#11456923)

It's a well known result that one time pads are provably secure. (Also, no PRNGs are involved.)

[ Parent | on HN ]

Re:If You Can’t Break Crypto, Break the Client: Recovery of ... by duaneb on Friday April 08, 2016 @06:42PM (#11458685)

The PRNG is certainly involved in the generation of the one-time pad. You could tell if they used the ascii text of hamlet.

[ Parent | on HN ]

Re:If You Can’t Break Crypto, Break the Client: Recovery of ... by sneak on Friday April 08, 2016 @08:35PM (#11459247)

Using a PRNG to generate an OTP is called a stream cipher, and then it isn't an OTP. :)

When using an OTP, you have to use non-pseudorandom values to avoid just being a stream cipher. If you're doing that, you can skip sharing the pad and just share the initial state of the PRNG.

If you go to the trouble of sharing the pad, go to the trouble of using random data within it. :)

[ Parent | on HN ]

Re:If You Can’t Break Crypto, Break the Client: Recovery of ... by rthille on Friday April 08, 2016 @07:21PM (#11458918)

Could be actual random data is used, rather than a PRNG

[ Parent | on HN ]