twr

7 ปีที่แล้วdiscuss

Apple also weirdly limits the capabilities available to free developer accounts, like AutoFill and built-in IPSec/IKEv2 VPN support.

https://help.apple.com/developer-account/#/dev21218dfd6

twr

8 ปีที่แล้วdiscuss

If you didn't trust the closed source disassembler you use, for whatever reason, you would verify the assembly output, not the actual software. In practice this is often done unintentionally anyway: it's common to run a debugger (ex: gdb, windbg) alongside an annotating disassembler (like IDA). objdump (from GNU binutils) also supports many non-Unix executable formats, including PE (Windows) and Mach-O (OSX/iOS).

For fun I just compared objdump's entry point function assembly of a downloaded Pokemon Go IPA to the Hopper representation, and, no surprise, they are identical.

twr

8 ปีที่แล้วdiscuss

This is a good point, which should be brought up more. Although you probably meant key id or key fingerprint, not keyserver ID, which would imply something else.

You're supposed to do additional verification of PGP keys, either through attending key signing parties (who does that in 2018?), checking the signatures of people you already trust, or comparing as much out-of-band information as you can.

It's not terribly hard to create a plausibly trusted keyring from scratch that depends on only 1 of 3 websites being legitimate. For example:

    kernel.org: ABAF11C65A2970B130ABE3C479BE3E4300411886 Linus Torvalds <[email protected]>
    marc.info:  647F28654894E3BD457199BE38DBBDC86092693E Greg Kroah-Hartman <[email protected]>
    thunk.org:  3AB057B7E78D945C8C5591FBD36F769BC11804F0 Theodore Ts'o <[email protected]>

All keys are cross signed as shown by gpg2 --list-signatures.

If this sounds like a pain in the ass, it's because it is, and GPG could be so much better.

Ironically, if you can't acquire the developer's public signing key, it might be best to install software directly from their website, if no trusted repositories are available. If you can acquire their signing key, it's probably best to not install software directly from their website, in order to avoid selective distribution attacks. Sort of unintuitive.

twr

8 ปีที่แล้วdiscuss

Linux/BSD distribution mirrors don't control the package signing keys, maintainers do. Similarly, Google doesn't possess the ability to push out updates for third-party apps, without fundamentally redesigning the OS with a platform update, because the signing keys are owned by the app developers, and the existing OS rejects updates signed with different keys. In both of these situations, the key owners lack the ability to selectively push out signed updates, unless they also control the distribution infrastructure.

twr

8 ปีที่แล้วdiscuss

No, there's no effective difference between those examples, apart from maybe post mortem analysis. It's also a poor method of key discovery, as hueving said.

twr

8 ปีที่แล้วdiscuss

It doesn't take ridiculous confidence to analyze shell scripts. In the hundreds of scripts I have read, few were more than 100 lines long. It shouldn't take more than 60 seconds (probably 30 or less) to mentally build a list of all possible operations a short script can perform. Bourne shell scripts don't have much room to hide surprising behavior, and when they do, it immediately stands out. If they are permanently installed, and invoked later by other parts of the system, then they may need more probing, but we're talking about installation scripts.

.deb and .dmg can be easily extracted. The former is just an `ar` archive containing tarballs, which you can (and should) extract to read the install scripts. (.dmg specifics escape me, since I only dealt with them one time, years ago.)

Binary code isn't inscrutable. Some good tools for this are, among many, many more, IDA, Hopper, and radare2. How long this takes depends on what your goals are, how comprehensive you are, and the program complexity. I don't think I've yet spent years on one project, fortunately, but the months-long efforts, for undoing some once-prominent copyright protection systems, were pretty brutal. Smaller programs have taken me just several hours to appropriately examine.

twr

8 ปีที่แล้วdiscuss

I agree with you that Keybase should release their backend code. My comment about (server source code- derived) trust was made in the context of users who would remain using the official keybase.io API servers, which would probably be the vast majority of Keybase users.

It’s not all of the time, or even most of the time, but frequently there are reasons for preferring binaries:

- build systems which are more annoying to setup than just straight reading the assembly / IL dump (ex: android)

- you might want to reverse and/or edit the binary anyway — to look at compiler output, as one example

- it’s sometimes faster to understand the asm than it is to go over the code, compile it, and compare [non-]matching binary outputs (this is regularly true for smaller programs)

- the tools for analyzing binaries are often more advanced than code tools

twr

8 ปีที่แล้วdiscuss

I didn’t dispute the description of Keybase being labeled a walled garden. I opposed it being too-broadly called proprietary, when it’s not — only the backend is. And for anyone only using the official keybase servers, that’s irrelevant from a trust perspective, which is the reason people usually (mistakenly) bring up source code availability.

Now I’ll also partially dispute the accusation of it being a walled garden, since walled gardens don’t have open specifications and documented APIs for third-party client implementations.

The backend source code would be good to have, for the prudent reason you pointed out, as well as for private instances, but that’s not enough: you also need client code modifications to allow configuration for custom servers.

About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)

twr

8 ปีที่แล้วdiscuss

I'm glad the mobile apps don't download code, and I really appreciate the correction on Lavabit; ugh, that project was embarrassing. I'm personally not happy with auditing local clients unless I have a mild assurance that other participants are running the same code, at some point, which can't be achieved with the web.

twr

8 ปีที่แล้วdiscuss

Considering the whole point of end-to-end encryption is to reduce or eliminate necessary trust in the middleman, this seems like a minor, but still valid concern. Open sourcing the backend code wouldn't allow you to attest to what's running on the server. If the clients also allowed you to point to a custom server URL, which I would support, then the source availability might matter.

twr

8 ปีที่แล้วdiscuss

Proprietary? The backend maybe, but the keybase clients are open source. Some of the code is a little rough, and completed API docs would be nice, especially concerning KBFS, which is still missing. It's still under heavy development though, so these shortcomings should be understandable. (I personally won't use it much until I can actually develop my own non-reverse-engineered client, but that's just my requirement.)

I'm guessing you meant non-decentralized?

twr

8 ปีที่แล้วdiscuss

The quote is from the front page of protonmail.com, and it's been there since 2015. As the only description of encryption on the front page, it gives the unequivocal impression that all email is end-to-end encrypted.

Regarding email between ProtonMail users, Lavabit once claimed "Our team of programmers answered with a system so secure that even our administrators can’t read your e-mail." Which is very similar to your claim, "even we cannot decrypt and read your emails." Lavabit was then asked to give up its TLS key, to evidently allow impersonation and delivery of malicious JavaScript designed to exfiltrate "non-decryptable" data. ProtonMail users are vulnerable to the same attack if anyone in a conversation ever uses the web interface. Or the mobile app, if it's just a web view.

In contrast, native SMTP+IMAP (+-E2E) clients are not typically developed by the email service provider, making orchestrated compromise much more difficult, and users can benefit by performing actual audits themselves because their email client hopefully doesn't fetch malleable remote code at runtime.

1. https://web.archive.org/web/20151116024152/https://protonmai...

2. https://web.archive.org/web/20130115080859/https://lavabit.c...

twr

8 ปีที่แล้วdiscuss

secured automatically with end-to-end encryption is a funny way of saying secured automatically with TLS. If some messages are being encrypted on the server, then it's not end-to-end. (I'd also argue that end-to-end encryption can't be meaningfully done in the browser, further reducing its typical security to the lowest common denominator: TLS.)

twr

8 ปีที่แล้วdiscuss

I mean, if you want visceral, there is this shameful email from Dan Harkins:

https://www.ietf.org/mail-archive/web/tls/current/msg10971.h...

twr

8 ปีที่แล้วdiscuss

I think this sentiment explains half of the negative reactions I’ve seen towards Moxie over the years. I guess it pays to be likeable.

twr

8 ปีที่แล้วdiscuss

I don't know if this is correct, but, I once got the impression that Signal Desktop was under the sole purview of a new hire at OWS. In other words, Moxie doesn't review the commits. I hope I'm wrong, but even if I'm not, I suppose it makes no difference, as he's arguably responsible either way.

twr

8 ปีที่แล้วdiscuss

Given the absent security of desktop Linux, and the dreadful opsec of its users, as revealed by many cryptocurrency wallet thefts, I wouldn't place much trust in persistent PGP secrecy unless all participants used Heads, and renewed keys regularly, and ran nothing except gpg. How many people do that, in the entire world, do you think? A hundred, at best?

twr

8 ปีที่แล้วdiscuss

Signal, WhatsApp, Matrix et al. show notifications when the participant’s device keys change. You’re right that most users don’t verify. The opportunity for detection or prevention of common forms of surveillance is better than none at all.

twr

8 ปีที่แล้วdiscuss

Again, you can be sure, by comparing the safety numbers. It's the same as comparing SSH or GPG key fingerprints. If someone else masquerades as Bob, the numbers won't match. See section III-D3, key fingerprint verification: https://www.ieee-security.org/TC/SP2015/papers-archived/6949...

twr

8 ปีที่แล้วdiscuss

It isn't. I rarely send sensitive messages, however, so I feel that some surveillance potential is acceptable, to save time and effort. The few times where I did, I first verified both ends.

I perform the safety number verifications in exchange for forward and backward secrecy. GPG isn't enough to establish a truly confidential communication channel, I think. (Unless you erase keys after every sent message, maybe.)

I'm not happy with Signal's dependence on a phone. Ideally I'd like to use a pocket-sized SBC for secure messaging. Come to think of it, that sounds rather like a phone. Just, uh, without the cellular hardware, and with a user-installed OS.

Submissions

Intra-Process Memory Protection for Applications on ARM and X86 [pdf]

comments