adi at hexapodia.org
Fri Aug 22 17:50:34 PDT 2014
On Thu, Aug 21, 2014 at 06:34:31PM -0700, Tony Arcieri wrote:
> All that aside, JackPhone seems like an unwieldy, impractical solution
> which despite its open source implementation leaves a lot of questions to
> be answered. How does it generate random numbers which it needs for its
> alleged forward secrecy enabled key exchange? Are they good?
In a quick scan I don't see which SoC JackPair is using, but they're
prototyping with reasonable 32-bit ARM chips, most of which include a
high quality HWRNG. (The STM in particular has a good reputation.)
What they're trying to build is fundamentally pretty possible, but there
are plenty of engineering challenges.
If I'm understanding their design correctly, they're taking the user's
voice and compressing and encrypting it, then encoding the encrypted
data as audio to send to the far side.
If so, they'll need to define a modulation to transport their encrypted
data stream over a voice channel. Doing this in a way that will work
reliably over the high latency, multicodec, bizarrely lossy cellphone
network is nontrivial. Getting it to demoable quality is pretty easy,
getting it to work well when the cell signal is fading in and out will
be lots of fun.
> I think JackPair is silly. If you want to make encrypted phone calls,
> use ZRTP, i.e. RedPhone or Signal. Perhaps JackPair would be cool in
> some sort of highly unusual activist use case, probably not involving
> comms over POTS.
It seems a little silly to me too, but I'm encouraged to see new
innovations in end user security systems, especially when they're not
trying to do something fundamentally impossible and seem to have a
reasonable grasp of what's required.
More information about the Messaging