RichardH

That is correct. You might want to store your safe on shared storage (for instance a NAS, or cloud storage like OneDrive) to keep your safe synchronized across all your devices. Richard. On Saturday, December 27th, 2025 at 3:29 AM, Lawrence R Horgan stretchnm@users.sourceforge.net wrote: Thanks Richard. I'm going to try using the keys on my other databases. I suspect that I'm going to need to copy the main PSafe file to the other devices first, otherwise they won;t know that a Yubikey has been set...

There is no need to setup anything on your other devices, you can unlock your safe(s) with your yubikey straight away. As you already suspect, repeating setup would overwrite the secret key on the yubikey. Richard. On Thursday, December 25th, 2025 at 2:10 AM, Lawrence R Horgan stretchnm@users.sourceforge.net wrote: I run PSafe on 4 PCs now. On my main PC (using WIn 8.1 and PSafe ver 3.64), I have set up 2 Yubikeys and practiced removing it from 2FA and adding it back in. Works great. I have NOT set...

There is a small detail wrt the security of the defaults, as those tend to weaken over time. A good example is the 2.000 iterations default set by TrueCrypt, which was apparently considered secure at the time. That means, setting a secure default now probably means that it will not be considered secure 10 years from now. Yet you cannot change the defaults as that would impact non-technical users not being able to mount their containers/disks anymore. So over time, all users likely need to use non-default...

That is extremely helpful, thanks! Changing big->little endian (both data and keys) makes the two match. 👍

The XTS with 256-bit blocks stuff is definitely interesting, looking at that now. Having some difficulty aligning SHACAL-2 output, for example, looking at your test.c unsigned char k1[64] = {0x00, 0x00, 0x00, 0x80}; unsigned char pt1[32 * 4] = {}; [...] printf("expected: 32B61A36A7E7A92F8D8123BBBD019E8373F4FDDADD6E4205B9ED7A29AE2B20F6\n"); the input matches a known test vector from https://github.com/weidai11/cryptopp/blob/60f81a77e0c9a0e7ffc1ca1bc438ddfa2e43b78e/TestVectors/shacal2.txt#L4 Comment:...

Yeah, I already extended my scrypt to support other prf's. I focused on version 2 indeed, good to know that v1 is not worth the trouble, thanks. If you ever create v3, it might make sense to align the two 64bit counters on 8-byte boundary to make it easier to read these values cross-platform. My initial release will support AES/Whirlpool only. Other options follow shortly in updates after that. Proof-of-concept is working nicely, here's a screenshot taken on Windows and iPhone simulator.

Just a FYI, as you might be interested to know that I decided to add ProxyCrypt support, which will allow accessing the contents of a disk image on iOS and macOS. read more

While I fully agree that it is technically possible to use a different hash function (or use a completely different PRF instead of HMAC for that matter), the specs for scrypt are pretty clear on HMAC-SHA256 being required, like in the RFC the algorithm starts with Initialize an array B consisting of p blocks of 128 * r octets each: B[0] || B[1] || ... || B[p - 1] = PBKDF2-HMAC-SHA256 (P, S, 1, p * 128 * r) Similary, the original paper defines a MFcrypt (which matches your usage), and then defines...