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...
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 > 1. 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...
Hi, Both RFC 7914 and the original paper introducing scrypt seem to mandate SHA-256 as hash-function, why did you deviate from that and use Whirlpool or Keccak instead? I noticed the "#ifdef TEST_SHA256" in the source, is there any release that includes this?
AI is good at producing lots of text while leaving the question unanswered. It will provide an equally detailed answer arguing that PBKDF2 and HKDF provide similar strength security.
I am trying to understand the difference. With the existing setup, if one cipher of a cascade is compromised, only part of the full PBKDF2 derived key is exposed. As the other parts are independent, they are not exposed. In what sense does HKDF make this more secure? As I currently see it, to break PBKDF2 you would need to break the PRF (and then some more), which would seriously impact HKDF too. But I could be wrong. Don't get me wrong: The elegance of HKDF is clear to me, I just don't understand...
For people downloading the .exe (which is most common) there is actually another signature which is easier to check: just right-click the exe and select Properties -> Digital Signatures. Select the embedded signature and then Details. In the dialog that appears there are two items to check (see attached screenshot). Anyway that's how I do it 😀
Agree, your previous comment on that makes a lot of sense too. My personal focus is on mobile platform where apps are restrained by the OS (500 MB ok, but GBs not ok), so for that case being able to tweak in units of MBs (like it is now) is better than GBs. The 3-field input you suggested could easily allow that of course. Changing the default as I previously suggested is only relevant if the current logic is kept.
Would it make sense to use default PIM value 485 for Argon2 too (instead of 12)? Suppose somebody uses PIM 750 for extra security on PBKDF2 based disk and enters wrong password. VeraCrypt will try all PRF's with PIM 750 so Argon2 will be tested with very high parameters (60x the default) compared to other PRF's. Why introduce the difference? Could be as simple as dividing by 40 and feeding that into the existing formula.
Could you elaborate on this part: once one segment leaks, the remaining two segments are completely determined Focussing on PBKDF2, each generated block T_i is independent of other blocks, e.g. you can calculate T_64 without knowing T_0...T_63. In what sense does leaking the first segment determine the other segments? Assuming of course the password is not leaked.
The iPhone/iPad app offers copy email/URL: entry context menu or single tap when viewing fields. The compose new email option is not yet available, will be after the next update :-)
Hi Michael, Great that you found the forum. I have copied your two questions to two separate posts there (one for each question allowing to discuss them separately): Locking AutoFill Make sure to click the green Follow button there as you didn't start the thread yourself, that will automatically notify you when new comments are added. I will answer both later today. Richard.
Hi Michael, I'm a bit biased, but it might help to add that our Mac version uses the core components of Password Safe. This provides maximum compatibility and security, as these components are battle-tested. Richard.