Hi @greysonp

> Once you’ve enabled secure backups, your device will automatically create a fresh secure backup archive every day, replacing the previous day’s archive.

So IIUC backups will not be incremental and I will have to re-upload my 15 GB backup archive every day? Why is that? What's the security risk here? (Obviously I'm not suggesting encrypting & uploading each message & media file individually but splitting things up into same-sized chunks, like e.g. borgbackup does.)

> At the core of secure backups is a 64-character recovery key that is generated on your device. This key is yours and yours alone; it is never shared with Signal’s servers. This key is different from your Signal PIN, which serves different purposes.

Both recovery key and Signal PIN seem to serve the exact same purpose, though, namely restoring data (conversations, contacts, account, …)? Why not unify them?

▲

elvisloops 6 days ago | parent | next [-]

Giving people a 64-character key also feels uncharacteristically crude for Signal. It's not realistic to hand people 64 characters and tell them to “store this securely.” Most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.

That's less of a problem when the backups are local, because access to the local backups implies access to the device, but if the backups are in the cloud with no forward secrecy, this seems like a huge security backslide for Signal.

▲

codethief 6 days ago | parent [-]

I get your point but is a large set of dictionary words or 5-digit numbers (see the current backup passphrase) so much better? At the end of the day, recording entropy will always be cumbersome and there is no way around it.

> Most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.

At least on Android apps can disable screenshots, though, which might be a simple way to deter people from doing that?

▲

dlgeek 6 days ago | parent | next [-]

I think a large set of dictionary words are likely more user friendly. I think most people will have a lot more confidence on their ability to transcribe words to/from paper more accurately than a bunch of numbers - better built in error correction, etc.

	▲	itake 6 days ago \| parent [-]
		Sanely formed numbers (like 4 digit groups with a checksum) seems like less writing to me, b/c I hate my hand writing.

▲

eviks 6 days ago | parent | prev [-]

> is a large set of dictionary words so much better?

Yes, much easier to type

	▲	cyphar 6 days ago \| parent [-]
		And much easier to copy elsewhere or memorise (not that I would recommend the latter).

▲

EGreg 6 days ago | parent | prev | next [-]

The PIN is a lot easier to guess on a remote machine storing a backup, the space is small. In the context of your device, they can throttle it.

	▲	codethief 6 days ago \| parent [-]
		Ah yes, the Signal PIN is backed by Intel SGX to ensure it can't be hacked even if the user has not provided enough entropy. However, why not simply rule out the low-entropy case altogether and use that randomly generated 64-character key throughout? That way, we also wouldn't have to trust Intel SGX… (which I think we shouldn't)

▲

greysonp 6 days ago | parent | prev | next [-]

Hi there!

> So IIUC backups will not be incremental

Nope! It's very much incremental :) At least the media is. There's one blob of containing all of your messages+metadata which does have to be re-uploaded every night, but for most people that's gonna be somewhere in the low-tens of MB. Your attachments are uploaded incrementally one at a time, typically as they're sent/received, so you usually don't even have to wait to upload them at backup-time.

> Both recovery key and Signal PIN seem to serve the exact same purpose, though, namely restoring data (conversations, contacts, account, …)? Why not unify them?

This was a hard decision and something we went back and forth on. But at the end of the day, we felt the safest thing we could do for now is to use a completely separate strong, random key. We're very aware of all the trade-offs involved, but this is where we landed.

	▲	tgsovlerkhgsel 6 days ago \| parent \| next [-]
		Thank you for choosing the "strong random key" rather than "sketchy PIN+SGX" option. This decision recovered my trust in Signal after the previous Signal PIN fiasco.
	▲	codethief 6 days ago \| parent \| prev [-]
		> Nope! It's very much incremental :) That's great to hear, thanks so much!

▲

wooptoo 6 days ago | parent | prev | next [-]

I'm assuming the backup format uses a container (like Veracrypt volumes), which grows in size forever, and cannot be backed up incrementally. I ran into the same issue when backing up loopback LUKS volumes. An elegant solution in this case was switching to Gocryptfs which encrypts each file individually, but then can mount the entire folder as a whole with fuse. This means only modified files need to be synchronised to the remote.

▲

highwind 6 days ago | parent | prev [-]

I'm guessing the same reason why my house's front door and back door use different keys.

	▲	tymscar 6 days ago \| parent \| next [-]
		Most likely they have different keys for absolutely no other reason than the fact that they were bought/made separately. I honestly would prefer to have a single key to my building.
	▲	nimchimpsky 6 days ago \| parent \| prev [-]
		[dead]