Lavabit Redux?

Anyone know anything about https://unseen.is/ ? It looks quite lavabitty, but it’s a new one on me. I’ve been tasked with helping out on a podcast about privacy and suchnot, and this is one of the links they sent me. Anyone more in the know care to chime in? Cheers in advance folks.

Howay, folks better at this than me. Anyone? Bueller?
@fuzzyfungus, @PrestonSturges isn’t this kind of your bailiwick?

NVM, it’s clearly dodgy as fuck, which I should have discovered from a cursory google.

1 Like

I’m afraid that I’m hardly the expert (although cynicism and paranoia appear to be depressingly good heuristic tools when it comes to security…); but I took a look:

Their backstory makes me a trifle nervous. ‘Proprietary’ is usually a synonym for ‘dangerously ill tested’ when it comes to encryption systems. However, they make multiple references to using NTRU, which is not a proprietary encryption system(though the 1996-era patents aren’t quite exhausted yet, and it appears not to be widely used). How this relates to their assertion that publicly available crypto systems are all cracked I leave as an exercise to the reader, as I have nothing close to the expertise required to compare NTRU with the better known ones, just the knowledge that this sort of evasiveness feels a bit off.

What is also a trifle curious is that (despite a stated belief in AES being broken) it sure looks like they either still do, or are reusing code from something that did, use a fair bit of it. I made a test account and tried a password reset. The JSON blob that was generated was not wildly enlightening(no plaintext passwords, thankfully, though I can’t identify how they were munged on sight); but “encryptionType=XAES” struck me as odd. aes.js also shows up in the ‘mail’ portion of the system(which appears to be roundcube based, though mention of that, or its GPL3 licensing terms, appears scarce).

Also slightly disconcerting is that, despite the FAQ specifically mentioning that the encryption key is either held solely by the user or encrypted with a passphrase, so as to never be available to the operator, my test account is currently running without a passphrase and I can’t find a place to generate one. There are convenience reasons why a user might wish to not have a passphrase; but it’s not a good default.

I would also be curious to know exactly why a security-oriented email client is using googiespell and the roundcube autocomplete functions. Hopefully neither of those are leaking anything back to the mothership.

Makes me a trifle jumpy, on the whole.

1 Like

Cheers. More technical insight than I gleaned, thanks. It sure looked shady tho. Shame, another real lavabit would have been good, no?

This topic was automatically closed after 931 days. New replies are no longer allowed.