4 ms·

>I believe LUKS is capable of that Booting into a 30 GB partition on a 128GB phone is going to be mega suspicious, even if the remaining data is random.

• inigyou 3mo ago
  Right, it would have to be 64/64 for everyone.
• cromka 3mo ago
  There are ways around it AFAIK.
  • gruez 3mo ago
    There really isn't. You can try avoid the "30GB volume on 128GB phone" problem by putting the hidden volume inside the free space of another volume, but since the outer volume doesn't know about the hidden, you have to be very careful not to overwrite the inner volume contents. The safest way would just be to not use the outer volume, but that's also suspicious. Who carriers around a phone that doesn't have any activity for months/years? Not to mention trim/discard means that free space will get wiped by default, and disabling it also makes you stick out like a sore thumb. You're better off traveling with a wiped phone, and restoring from backup after you've crossed.
    • dredmorbius 3mo ago
      Who carriers around a phone that doesn't have any activity for months/years? An activity-generator might help address that.
      • gruez 3mo ago
        Well the activity generator is going to have to be very careful to not accidentally overwrite data on the hidden volume, and somehow able to hide itself from adb or forensic tools that it's enabled.
        • dredmorbius 3mo ago
          Those are ... relatively minor concerns. Firing off as part of a duress key entry, and removing itself (from the decoy partition) as its work is done, would suffice. ADB / forensic tools would be ineffective if USB access is denied (as discussed elsewhere in this thread).
          • gruez 3mo ago
            >ADB / forensic tools would be ineffective if USB access is denied (as discussed elsewhere in this thread). Well no, because if you gave the pin, you'd expect the phone to work normally, including enabling adb. If you gave the pin but adb doesn't work that would be massively suspicious. Same if adb worked but logs were scrubbed. Otherwise you're back at "border guards found out you gave a duress pin, now you're being prosecuted for tampering with evidence".
            • layla5alive 3mo ago
              It doesn't feel like you're very interested in solving this problem - you seem more interested in defending the status quo
              • dredmorbius 3mo ago
                In fairness, an adversarial challenge can be useful in pointing out weaknesses (and possible mitigations) to a particular technical approach. It's not clear that all of those objections are substantive or insurmountable. "The USB port may have died" might be one possible response. (Not technically a lie, and hence defensible in court.) Or just silence. Alternatively, some way of directing such probes to the decoy partition and presenting a sufficiently coherent impression of a valid partition might be another approach. Much of this comes down to risks presented and costs of mitigation (or of getting mitigations wrong).
                • gruez 3mo ago
                  >"The USB port may have died" might be one possible response. (Not technically a lie, and hence defensible in court.) Or just silence. That's about as convincing as "wow this phone just decided to experience catastrophic hardware failure after entering your totally-not-duress pin". Not to mention there's wireless adb. >Alternatively, some way of directing such probes to the decoy partition and presenting a sufficiently coherent impression of a valid partition might be another approach. That won't work because they'd notice the adb logs don't correspond to actions taken on the actual phone. >Much of this comes down to risks presented and costs of mitigation (or of getting mitigations wrong). Right, which is why grapheneos didn't bother implementing it, because it's a huge effort and it's not worth giving users a false sense of security (eg. thinking that the decoy works when it doesn't), and them getting sent to prison for it.
• dredmorbius 3mo ago
  A partition based on a sparse disk image might avoid that. You'd have what appears to be a 128GB image (or some large fraction of that), which in reality is largely holes (typically: repeated blocks of ASCII 00 bytes). Of course, you'd need to avoid actually trying to fill that filesystem.