petedoyle
Joined 15 years ago
Karma
310
Submissions
70
Member since
Mar 19
Recent submissions
Comment · 8 months ago
Wow, I'd love to do this. Any tips on how to build this (or how to help an LLM build this), specifically for ./gradlew?
Comment · 1 year ago
The U.S. Missile Defense Agency (MDA), in cooperation with U.S. Space Force and U.S. Northern Command, conducted a flight test on June 23, 2025, in which the Long Range Discrimination Radar (LRDR) at Clear Space Force Station, Alaska, successfully acquired, tracked and reported missile target data to the Command and Control Battle Management and Communications (C2BMC). This was the radar’s first flight test tracking a live Intercontinental Ballistic Missile (ICBM) representative target. More: https://www.mda.mil/news/25news0006.html
Comment · 1 year ago
Apologies / small correction:
Apps first published to the Play store before August 2021 are not required to upload their keys [1]. This likely includes Signal.
Comment · 1 year ago
Maybe this? https://en.wikipedia.org/wiki/MUSCULAR
Comment · 1 year ago
> The absolute nightmare is about giving Google the root signing key of your application
I wish more people talked about this. At Amazon, I helped with the early threat modeling around adoption of "App Signing by Google Play", which requires sending your app's root signing key to Google (and is now required, with no publicly-available opt-out for new apps.) It would have added some nice things for Android devs: app bundles, smaller downloads, instant apps, etc.
That said, we imagined the following scenario, and were unable to find a reasonable mitigation at the time:
It seems plausible the US government could send a NSL (or similar) to Google and force them to distribute modified APKs for apps like Signal (ex: to exfiltrate keys). This would be nearly impossible to detect, especially if the modified APK were distributed to only an individual user, or a small group. A few people raised concerns [1], but I don't recall Google ever giving a reasonable response.
[1] https://commonsware.com/blog/2020/09/23/uncomfortable-questi...
Edit: clarify no opt out applies to new apps
Comment · 1 year ago
Somewhat off-topic: Does anyone know the underlying strength of the keys used as the "root of trust" behind passkey synchronization on Android/iOS? I can't find a lot of documentation on this.
It seems like they're synced between devices using client-side encryption, with keys derived from your phone's lock code (typically only 4-6 digits). Is it possible that the passkeys are fully random, but then encrypted with far less than 128/256 bits of actual entropy while being synchronized between devices?
Could it be possible to brute force the keys server-side (IIUC, derived from 4-6 digit pins) with non-excessive amounts of compute? What am I missing?
Comment · 1 year ago
I didn't know him, but followed his work on bufferbloat closely. I've never seen anyone work so diligently, for so many years, to fix a problem most people will never know even existed. And yet, that work will be felt by almost everyone on the internet. I'm sad knowing he's passed, and thankful to have seen his work. Rest in peace.
Comment · 1 year ago
Oh, looks like it. I disabled extensions one by one til I found it was reflect.app's extension. Edit: reported on their discord.
False alarm :) Amazing work!!
Comment · 1 year ago
Small FYI that I couldn't see them in Chrome 133.0.6943.142 on MacOS. Firefox works.
Comment · 1 year ago
If Apple were to add new APIs, it might be possible to use personal cloud storage (NAS, Decentralized Web Nodes, etc.) with the same UX as iCloud with E2EE.
Comment · 1 year ago
Maybe they wanted some cached data to get invalidated if users change their passwords?
Comment · 3 years ago
Would be fun if this turned into a huge recruiting event :)
Comment · 3 years ago
> Sure, but if that key derivation function is protected by a "you get 10 attempts then we wipe the keys" safeguard, the effective entropy is much higher.
Thank you. 100% agree.
> Passkeys do not and are not designed to protect against nation-state level attackers
I've been mulling over some use-cases where this is important, hence the deep consideration over entropy. 100% not a huge deal for the passkeys case for many 9's of people.
Comment · 3 years ago
Thank you! I'm trying to understand more deeply, so I appreciate it. :)
> This approach works because the secure enclave provides measures against bruteforcing and tampering.
That's interesting!
> because that implies off-device use of the PIN, so those measures are lost
This link from your previous thread is interesting: https://support.apple.com/en-sg/guide/security/sec3e341e75d/...
Uses SRP to let the device prove to iCloud HSMs that the user entered the correct pin, without ever sending it over the wire. The HSMs have similar protections for brute forcing, etc.
From the docs I have a fairly high confidence entropy is 256 bits for iCloud Keychain. I have much less confidence on Android, but I'm still researching... :)