By the ones they were issued by Apple/Google when they signed up for the dev accounts?
If Apple/Google want to backdoor Signal they can do so, they can also backdoor your device in this case the signature check is irrelevant if you consider them an adversary.
If you build your own using the source code then signing sourcecode effectively is near impossible since any change to it would require it to be resigned and even copy paste will likely to break the signature since now you are dependant on the encoding (ASCII/ANSI/UTF8/UTF6) and how your text editor handles spaces and tabs...
If you sign source code files you also somewhat defy the purpose of open source which is having the code be inspectable and if you do build from open source repos you either trust the repo (github in this case) and the repo is your adversary you should either not take any code from it at all or inspect every line of it manually.
Signing anything can be irrelevant or it can be critical it all depends on what are your threats and who are your adversaries.
In this case if you trust Apple/Google not to backdoor applications or your device; signature beyond what is offered by their platform is irrelevant; in any case since the signature verification is on the device if they are your adversaries there is little you can do about it since they can backdoor the verification procedure or your device in it's entirety meaning that you can't trust it.
If you trust Github and OWS you can trust the source code; you know that the source code hasn't been tampered with in transit because you pull it via HTTPS and you can review the source code and any pull and merge requests, if you don't trust Github or OWS you have to resort to manual code inspection or not use Signal at all; again signing the code offers little to no security and in effect can lead to back practices such as blind trust rather than manual verification.
> If Apple/Google want to backdoor Signal they can do so, they can also backdoor your device in this case the signature check is irrelevant if you consider them an adversary.
What? No...
Assuming you trust OWS you can check the APK signature.
A) Nuke everything
B) Install ASOP or other OS that you prefer.
C) Download and manually checked Signal's signature.
D) Transfer it to your device.
No need to trust Google. Am I missing something?
Listen, you always need to trust SOMETHING. If you don't trust Google or OWS you can read their code yourself, but then you're trusting the compiler, the OS, the hardware, etc. But I submit that of the above some are inherently more trustworthy than others, given their track record.
You said that the play sore APK is signed. Signed by whom? By OWS, right? So Google can't backdoor it. Again, what am I missing? Help me out. I might be making a reasoning mistake due to not thoroughly understading how these things work (I mean APK distribution)
They are signed by the same process as all other APK's on the store; using the play store developer keys that OWS received.
Google can backdoor it because they control the distribution source and verification scheme.
Google can push anything they want to your device that's a given. Sure you can "lock them out" if you build your own android from AOSP (and even that is doubtful) but if you want to get Signal you'll have to install Google Play and the rest of the Google services which in effect will allow Google to backdoor your device if they would so desire too.
Now you can say well I can violate the EULA rip off the APK from the Google Play store on one device and copy it to my AOSP device and verify it there, you still can using Jarsigner; but this is not a distribution method OWS want or should support.
OWS trusts that Google and Apple will not backdoor the binaries and devices that is an axiom they base their threat models on; for them it's more important that all users would receive updates and use an upto-date version of Signal since this how how OWS ensures herd immunity; everyone is running more or less their latest software; all the security features are in play; they don't need to support legacy client; everyone is happy.
At the end it's simply a case of OWS distributes it's software via 2 channels Play Store and App store in both cases the binaries are signed and verified by the processes supported by Google/Apple.
Alternatively OWS allows you to download the source code from their Github repo and build the version of Signal for IOS/Android and sign it with any key you want.
So overall I don't see where do you want them to add additional signatures; what is your threat model?
It would be too easy to say "don't try to teach moxie how to do crypto" but this won't be interesting to either of us, I'm really curious what is your threat model that you would like additional signature specifically by OWS and what do you want them to sign.
> They are signed by the same process as all other APK's on the store; using the play store developer keys that OWS received. Google can backdoor it because they control the distribution source and verification scheme.
If I verify the signature, I can determine whether or not the APK has been tampered with by Google, yes or no?
> It would be too easy to say "don't try to teach moxie how to do crypto" but this won't be interesting to either of us, I'm really curious what is your threat model that you would like additional signature specifically by OWS and what do you want them to sign.
Well, obviously I'm not trying to teach anyone crypto as I don't know enough myself to begin with. My threat model is don't trust anyone that has a bad track record. In my book Google has a bad track record but not moxie.
When you say "doesn't meaningfully improve security", does "meaningfully" mean "for the majority of users"? Because I can assure you that for a single user who does things properly it does improve security.
I don't know, but am I right in saying that he is generally in favour of ephemerality over verifiability? It'd seem odd to do this with definitely attributable works like software releases, but it is what would make most sense to me.
> he is generally in favour of ephemerality over verifiability
That's not an absolute law in a vacuum. What does "ephemerality" even mean in the context of the question "how can I verify that the software that's being pushed to my phone comes from where it says it comes?"
26 comments
[ 2.0 ms ] story [ 83.5 ms ] threadMy guess is because of potential friction with reproducible building (for Android) and this for iOS: https://github.com/WhisperSystems/Signal-iOS/issues/1063
hth, adric
If Apple/Google want to backdoor Signal they can do so, they can also backdoor your device in this case the signature check is irrelevant if you consider them an adversary.
If you build your own using the source code then signing sourcecode effectively is near impossible since any change to it would require it to be resigned and even copy paste will likely to break the signature since now you are dependant on the encoding (ASCII/ANSI/UTF8/UTF6) and how your text editor handles spaces and tabs...
If you sign source code files you also somewhat defy the purpose of open source which is having the code be inspectable and if you do build from open source repos you either trust the repo (github in this case) and the repo is your adversary you should either not take any code from it at all or inspect every line of it manually.
Signing anything can be irrelevant or it can be critical it all depends on what are your threats and who are your adversaries.
In this case if you trust Apple/Google not to backdoor applications or your device; signature beyond what is offered by their platform is irrelevant; in any case since the signature verification is on the device if they are your adversaries there is little you can do about it since they can backdoor the verification procedure or your device in it's entirety meaning that you can't trust it.
If you trust Github and OWS you can trust the source code; you know that the source code hasn't been tampered with in transit because you pull it via HTTPS and you can review the source code and any pull and merge requests, if you don't trust Github or OWS you have to resort to manual code inspection or not use Signal at all; again signing the code offers little to no security and in effect can lead to back practices such as blind trust rather than manual verification.
What? No...
Assuming you trust OWS you can check the APK signature.
A) Nuke everything
B) Install ASOP or other OS that you prefer.
C) Download and manually checked Signal's signature.
D) Transfer it to your device.
No need to trust Google. Am I missing something?
Listen, you always need to trust SOMETHING. If you don't trust Google or OWS you can read their code yourself, but then you're trusting the compiler, the OS, the hardware, etc. But I submit that of the above some are inherently more trustworthy than others, given their track record.
If you want to do it your way get the source from github and build your own damn client.
If you just want to check that the google play apk is signed you can do that with the antoid sdk/jdk jarsigner works on apk files.
Also, no need to get triggered mate, we're just having a conversation.
The play store apk is signed the AppStore app is signed what else do you want to be signed?
Google can backdoor it because they control the distribution source and verification scheme.
Google can push anything they want to your device that's a given. Sure you can "lock them out" if you build your own android from AOSP (and even that is doubtful) but if you want to get Signal you'll have to install Google Play and the rest of the Google services which in effect will allow Google to backdoor your device if they would so desire too.
Now you can say well I can violate the EULA rip off the APK from the Google Play store on one device and copy it to my AOSP device and verify it there, you still can using Jarsigner; but this is not a distribution method OWS want or should support.
OWS trusts that Google and Apple will not backdoor the binaries and devices that is an axiom they base their threat models on; for them it's more important that all users would receive updates and use an upto-date version of Signal since this how how OWS ensures herd immunity; everyone is running more or less their latest software; all the security features are in play; they don't need to support legacy client; everyone is happy.
At the end it's simply a case of OWS distributes it's software via 2 channels Play Store and App store in both cases the binaries are signed and verified by the processes supported by Google/Apple. Alternatively OWS allows you to download the source code from their Github repo and build the version of Signal for IOS/Android and sign it with any key you want.
So overall I don't see where do you want them to add additional signatures; what is your threat model? It would be too easy to say "don't try to teach moxie how to do crypto" but this won't be interesting to either of us, I'm really curious what is your threat model that you would like additional signature specifically by OWS and what do you want them to sign.
> They are signed by the same process as all other APK's on the store; using the play store developer keys that OWS received. Google can backdoor it because they control the distribution source and verification scheme.
If I verify the signature, I can determine whether or not the APK has been tampered with by Google, yes or no?
> It would be too easy to say "don't try to teach moxie how to do crypto" but this won't be interesting to either of us, I'm really curious what is your threat model that you would like additional signature specifically by OWS and what do you want them to sign.
Well, obviously I'm not trying to teach anyone crypto as I don't know enough myself to begin with. My threat model is don't trust anyone that has a bad track record. In my book Google has a bad track record but not moxie.
That's not an absolute law in a vacuum. What does "ephemerality" even mean in the context of the question "how can I verify that the software that's being pushed to my phone comes from where it says it comes?"