Taylor Hornby, a security researcher, publishes audits of encryption tools such as EncFS and eCryptfs, plus essays and small online tools like an x86 assembler.
HN commenters link it for the secure code delivery essay, the online x86 assembler, and its encrypted filesystem audits.
> EAX is not available in addresses.
Is this a relevant correction? If there is a point, ignore the following.
You seem to like the ATT syntax, which I avoid whenever I can. However, if there isn't a specific point, and we're just being pedantic or having a pissing match, copy the following:
mov rbx, [rax + 4*rax]
mov rbx, [eax + 4*eax]
movss xmm0, [rax + 4*rax]
movss xmm0, [eax + 4*eax]
into https://defuse.ca/online-x86-assembler.htm with the x64 option enabled. Your original example had float, so I included that as well. They all assemble, and the difference is in the REX prefix.
I haven't looked at it in a few years, and I've forgotten a lot of details, but I wrote my own x86-64 assembler for fun. And of course, like most assemblers, I improvised my own syntax and naming convention. In particular, I didn't make a distinction between EAX and RAX (or AX or ALO). To me, it's just register A, and I gave the opcodes more descriptive names to indicate the bit width.
I figure if gas can do something like ATT syntax, I can do my own my way.
VeraCrypt's on-disk format is NOT compatible with TrueCrypt's on-disk format,they are two totally different things and must be handled differently.
VeraCrypt binary application can unlock TrueCrypt volumes but CAN NOT create them.The application has a setting to default to TrueCrypt volumes and hence if all you do is unlocking your TrueCrypt volumes,you can conveniently use VeraCrypt to unlock your TrueCrypt volumes.
I think it will be better if you switch to VeraCrypt and set this option.Alternative "native linux" tool you could use to manage your TrueCrypt volumes in linux is zuluCrypt[3].
EncFS has its own issues[1] and there are a number of new projects that seeks to replace it and SiriKali[2] is a GUI tool to manage all these newer tools.
[1] https://defuse.ca/audits/encfs.htm
[2] https://mhogomchungu.github.io/sirikali/
[3] http://mhogomchungu.github.io/zuluCrypt/
An example where auditors not having the threat model did not help the audit: https://defuse.ca/audits/gocryptfs.htm
> We believe the reason these vulnerabilities exist is because gocryptfs doesn’t have a clearly spelled-out threat model. Some of the attacks seem hard to avoid given gocryptfs’s performance goals and may have been introduced “by design” to meet these goals. We suggest writing down an explicit threat model and updating the website to better communicate the security guarantees that gocryptfs provides. This way, users are less likely to rely on it in ways which would make them vulnerable.
Later established: https://nuetzlich.net/gocryptfs/threat_model/
You found the exception! Congratulations!
You're using a bucket size which is a power of 2. A random byte fits on the interval of [0, 255] which is evenly distributed modulo 256, which if you reduce mod 2^N for 1 < N < 8 will still produce a uniform distribution.
If you copied my JS code into your console and changed the 54 to 64 the bias evaporates. Hooray :D
However, for arbitrary ranges, you should use an unbiased selection strategy to ensure a uniform distribution.
http://3v4l.org/EgfPR - notice 0 is significantly more common than the other values when reduced mod 17
http://3v4l.org/LXmKq - same with mod 15
https://defuse.ca/generating-random-passwords.htm
> 1) We should absolutely work towards allowing developers to sign their JavaScript.
I've already been working on this for my own projects. It might be something that can be generalized for all Electron projects.
https://github.com/soatok/libvalence
https://github.com/soatok/valence-updateserver
https://github.com/soatok/valence-devtools
This uses Ed25519 signatures and an append-only cryptographic ledger to provide secure code delivery. The only piece it's currently missing is reproducible builds.
For greater context: https://defuse.ca/triangle-of-secure-code-delivery.htm
Details are described in audit that was performed for gocryptfs: https://defuse.ca/audits/gocryptfs.htm
> Against a less-powerful active adversary who can modify the ciphertexts but has no access to the mounted filesystem, gocryptfs keeps file contents secret and provides imperfect integrity protection. In at least one case, imperfections in the integrity protections lead to a break of confidentiality. It is possible that the integrity imperfections lead to further confidentiality breaks depending on which applications are using the filesystem.