twr

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

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.

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 <torvalds@kernel.org>
    marc.info:  647F28654894E3BD457199BE38DBBDC86092693E Greg Kroah-Hartman <gregkh@kernel.org>
    thunk.org:  3AB057B7E78D945C8C5591FBD36F769BC11804F0 Theodore Ts'o <tytso@mit.edu>

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.

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.

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.

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.

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

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.)

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.

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.

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?

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...

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.)

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...

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.

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.

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?

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.

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...

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.

Signal doesn't entrust security to carriers. Messages are sent E2E encrypted to the registered device over the internet. If someone MitMs a device, the safety numbers would not match on either end.

Signal, and the Signal server operators, malicious or not, do not know the phone numbers of people you are communicating with (presuming the secure enclave on the server isn't cracked). Signal does know your phone number, so someone could figure out if you use Signal. If you're worried about that, or personal sharing of your number, you could falsify information to create an anonymous phone number, or you can just use Matrix or Wire.

Unbound lets you forward queries to nameservers matched by the query (sub-)domain.

*.internal queries can be sent to the local nameserver, for example, while others can be forwarded to the public nameserver.

Minimal unbound.conf example:

    forward-zone:
        name: "."
        forward-addr: 1.1.1.1
    forward-zone:
        name: "internal"
        forward-addr: 10.0.0.1

https://twitter.com/realdonaldtrump/status/26589529219124838...

Edit:

https://twitter.com/realdonaldtrump/status/40897761692683059...

https://twitter.com/realdonaldtrump/status/41854213789949132...

Here's an alternative to wrapping GPG, using .gnupg/gpg.conf:

  personal-cipher-preferences AES256 AES
  personal-digest-preferences SHA256 SHA512
  personal-compress-preferences Uncompressed
  default-preference-list SHA256 SHA512 AES256 AES Uncompressed
  
  cert-digest-algo SHA256
  
  s2k-cipher-algo AES256
  s2k-digest-algo SHA256
  s2k-mode 3
  s2k-count 65011712
  
  disable-cipher-algo 3DES
  weak-digest SHA1
  force-mdc

You can just pipe xz instead, although you may want to shred the original file:

  xz < file | scrypt enc - > file.xz.enc

I didn't know Colin also wrote an encryption utility that uses the scrypt KDF. It does seem better than using GPG to password encrypt files.

When the system is installing an update to an app, it compares the certificate(s) in the new version with those in the existing version. The system allows the update if the certificates match. If you sign the new version with a different certificate, you must assign a different package name to the app—in this case, the user installs the new version as a completely new app.

https://developer.android.com/studio/publish/app-signing.htm...

If you want to install an update that was signed with a different private key, the app would need to be uninstalled first, which would also delete any sensitive data in private app storage.

This is enforced at the platform framework level, from what I loosely remember of scanning the AOSP source code.

Yes, Google could hijack packages sent to first-time downloaders. That's usually the downside with trust on first use. If the initial download isn't trustworthy, the whole verification scheme falls apart. It would be better off if Android had the APK equivalent of Certificate Transparency. That, and if Google Play made all developer-uploaded APK builds available to users, for awareness.

I was curious what that meant with "even if the server is malicious." Turns out, in short, the Mylar paper creates a distinction between the "web site owner," and "the server operator."

It shouldn't need to be stated, but not all people believe that is always an important distinction.

Mylar places complete trust in the application developer, whereas an important aspect of other security software is that you don't need to trust the developer: if one version of the software is audited, you can stay on that version; or the other can be examined.

Mylar doesn't make the web any less of an ephemeral and invisible black-box execution environment, where code goes in and vanishes without earlier proof of existence.

It sounds like I'm panning it, but really I think the idea is sound: It makes the lives of non-affiliated/non-government attackers more difficult. I'd use it with my bank website. Just not for highly sensitive communications.

Interesting. It makes sense to be strict when parsing stream input. Skipping the redundant central directory section hadn't even occurred to me. Bonus points for eliminating the stupid comment confusion dilemma!

On second thought, not entirely redundant, as the central directory does contain the file permissions. But those can be parsed and set after file extraction, without increasing the overall memory complexity.

That is an excellent explanation, thank you.