u/randombit

I can't speak to local opportunities but there are IME plenty of options for remote work for US based persons, and some CoL adjusted % of a typical SF/NY salary goes a long way here, probably better than anything you can get locally. Source: have done security work and software development remotely in Vermont since 2009.

It can be hard to get your foot in the door, some places are hesitant to hire remote especially people who don't have previous experience working remote. [COVID may have changed this feeling given everyone is now remote, not sure]. I've had good luck with taking contracts which led to full time offers, from companies which didn't ordinarily hire remote.

COMPANY: Fortanix (https://fortanix.com/company/careers/)

TYPE: Full time

DESCRIPTION: We build SDKMS which is an HSM-as-a-service using Intel SGX as well as EnclaveOS which allows running arbitrary services (eg MySQL) inside SGX enclaves. Basically everything we do is in Rust. All experience levels wanted.

LOCATION: Mtn View CA, or Eindhoven NL

REMOTE: Plenty of flexibility for WFH or working remotely for short periods. FT remote is not generally allowed but if you happen to also be very experienced in cryptographic software development it may be a possibility - if this is you, email me directly.

VISA: Yes

CONTACT: Via careers page or mail me at [email protected]

She's got you covered - https://practicalselfreliance.com/clean-gut-squirrel/

As far as I know there is nothing special about hunting vs any other activity. As long as it's not posted, you're not trespassing. (Unless the owner tells you to leave, of course.)

I work on a fairly large (million+ lines) C++ project that is built using scons. We have over 13,000 lines of scons code.

However my problem with scons is not that it takes a lot of lines - the build is doing a lot of different things (creating installers, running tests, a surprisingly large amount of code generation, 3rd party dependency management, etc plus of course actually running the compiler) so I don't feel the line count is unreasonable - but that it is slow. On my desktop, a no-op build of this project takes ~60-90 seconds while scons pegs a core before finally returning 'all targets built'. That poor turn around time compared to make really makes development harder and causes me to avoid scons anywhere I have the option.

Doing it over again, would you have chosen to write Tor in C? It seems like there is a tradeoff between performance and safety both of which seem highly relevant Tor, and I would be curious as to your take on the tradeoffs.

Also, can you think of any interesting tricks, design approaches, you've learned while writing safety critical code in a memory unsafe language?

In Vermont, you missed The Alchemist http://www.alchemistbeer.com/ and Lawson's Finest Liquids http://www.lawsonsfinest.com/

Both are small but the Alchemist has #4 on BA's top 100 and LFL has #27.

Which would make it an excellent way to launder large amounts of cash, since the input cash isn't tracked and the outputs are dispersed to many small winning tickets making it easier to quietly cash in without publicity.

Probably not. Given a finite amount of time, I think it likely I would focus efforts on avoiding timing/cache, oracle, and fault attacks. Even fault attacks I consider somewhat unlikely in the main context of the lib (desktop/server apps; I'm aware of only a few embedded systems using it), but it is possible to address some fault attacks in relatively generic ways that don't hurt performance overmuch.

In contrast (as far as I am aware) meaningful protections against DPA would hurt performance greatly, would only really matter to embedded systems, and in many cases would require explicit assumptions on how the CPU/cache behaves. It would be nice to have as an extension I suppose (if you are worried about such attacks you can choose to take the performance hit), but not something I would see having the time to work on anytime soon.

Safety wise it's equivalent to just putting it into a coffee can though - if a burglar bothers to examine it, he'll quickly see it's a safe. Even if it's not trivially easy to open (which I would guess it probably is), he'll grab it up for later hacksawing/sledgehammering at his leisure.

Oh, interesting! I didn't realize this, haven't got the book yet, but looking at the TOC it does indeed seem to be the same text. I assume you've already seen it, but for others checking the comments, DJB's website at http://pqcrypto.org/ has a lot of good information and references related to the book.

More typically, it was in in the form of PGP encrypted messages posted to groups like alt.anonymous.

This seems to be assuming a seriously good whole program optimizer. In particular, if some of your code is in shared libraries it seems like it would be quite difficult for the compiler to optimize RTTI away.

Can't say that I would ever use it. Posted entirely in the spirit of 'interesting technique, might be useful in some other context someday (or maybe not).'

In the Skein's case, n is the size of the input in blocks. So while this multiplication is indeed data-dependent, being able to construct a timing attack on it would only tell you the size of input blocks; for instance if the software using it used blocks of size 1024 bytes or 8192 bytes.

I will grant you this could in fact expose some information; for instance if the application in question was hashing data such that it first hashed in a single call a passphrase, followed by a single call adding in a salt, in order to compute H(pass || salt), you could determine the length of a passphrase. However, it's worth considering a) this only tells you the length modulo 64 (the Skein-512 block size), so you would only be able to say "this passphrase is less than, or more than, 64 bytes" and b) it is entirely possible, and quite straightforward, to implement Skein such that it wouldn't expose this information.

(Also, in the specific case of Skein, the block size of always a constant and a power of 2, so most any optimizing compiler will convert it to n << log2(SKEIN_512_BLOCK_BYTES), which is constant time on most if not all processors.)

In the BMW case, the i*0x0555555555555555ull calculation is not data-dependent - it uses the same values of i each time (16 to 32), and does not depend on the input data at all.

Reference please? I wasn't aware of any known timing attacks against Skein, CubeHash, Serpent, or indeed any cipher or hash that doesn't rely on data-dependent rotations, multiplications, or table lookups.

Merely length padding is not sufficient to prevent length extension attacks; all it means is that your extended message must include the length pad as prefix.

To prevent length extension attacks you need to add some sort of final output transformation. One way of hacking this into existing hashes is to nest the hash - SHA-256(SHA-256(m)). This was originally recommended in, IIRC, Practical Cryptography, precisely to prevent length extension attacks. The SHA-3 candidates which use MD designs also use final output transformations to prevent the attack. For instance to compute the digest in Blue Midnight Wish, you take the final MD output and then compress it as the input, using a fixed IV. Skein uses the final MD output to key a PRF.

Also, worth noting that not all of the SHA-3 contestants are Merkle-Damgard. For instance CubeHash or Keccak are not MD designs by any stretch.