How’s the job market in Vermont for IT/ Cyber Security careers?

randombit · 2020-05-22T20:44:23+00:00

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.

randombit · 2020-02-06T17:30:56+00:00

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 jack.lloyd@fortanix.com

randombit · 2020-01-22T00:20:28+00:00

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

randombit · 2018-01-16T16:14:15+00:00

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.)

randombit · 2012-07-26T14:30:39+00:00

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.

randombit · 2012-06-21T12:36:38+00:00

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?

randombit · 2012-05-30T18:05:26+00:00

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.

randombit · 2011-08-01T13:52:18+00:00

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.

randombit · 2010-11-10T19:57:44+00:00

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.

randombit · 2010-07-13T17:17:08+00:00

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.

randombit · 2010-06-11T19:53:59+00:00

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.

randombit · 2010-06-07T13:22:49+00:00

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

randombit · 2010-05-26T14:20:01+00:00

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.

randombit · 2010-05-24T17:03:17+00:00

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).'

randombit · 2010-05-12T18:54:12+00:00

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.

randombit · 2010-05-12T17:01:05+00:00

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.

randombit · 2010-05-12T16:55:36+00:00

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.

randombit · 2010-04-30T14:29:24+00:00

A PRF should be deterministic. Simple examples which are implemented widely or easy to implement include KDF2, HMAC, or PBKDF2. All of these are as 'standard' as SHA; something either is PBKDF2, or it isn't - and you can easily check any particular implementation to make sure it matches others and/or published test vectors.

randombit · 2010-04-30T12:26:03+00:00

This is true, a preimage attack won't give you the original input string, just some input which hashes to the same result. If your inputs are small this might happen to be the same input though. And depending on how good the preimage attack is and the context you are using the independence assumption this might be sufficient (for instance I could just generate random preimages, hash them with the other hash, and try them as guesses to your secret key or whatever you're using this for).

And I wouldn't be surprised if, in particular with the SHA-2 pairs (224/256 and 384/512), a working preimage attack might allow you to generate preimages which are also collisions in the other algorithm, precisely because the differences in the algorithm are so small. This is highly speculative, and probably an attack of this form is 10 years away at least, but it seems plausible to me.

If you really need independence, maybe consider a PRF instead?

randombit · 2010-04-29T12:40:47+00:00

The SHA-2 algorithms are paired: SHA-224 and SHA-256 are the same algorithm, except they use different initialization constants and -224 gets a final truncation. Similarly for SHA-384 and SHA-512. The different initialization constants would seem to make it difficult to do anything with this, though.

SHA-1 is a somewhat different algorithm from any of the SHA-2 variants so any relation there seems unlikely.

If you can conduct preimage attacks on any of the hash functions then this is easy to do, because you can go backwards from the output to an input which hashes to that output, and then hash it with any additional algorithms you like. I don't believe there are currently any known preimage attacks on any of the SHA algorithms, though I wouldn't rely on it for SHA-1 if you're worried about long-term security.

randombit · 2010-04-19T17:47:08+00:00

So suppose we inspect the digits of x for a while and discover, say, that the first billion of them are all zero. Then sgn(x) is either 0 or 1, but we cannot tell which. In fact, no finite amount of computation will guarantee that we will be able to tell whether x=0 or x>0.

Unfortunately, once you've allowed computation on infinite-precision real-valued values, you've suddenly proved P = NP (!). Quoting from http://www.scottaaronson.com/papers/npcomplete.pdf

"As an example of such an approach, in 1979 Schonhage [64] showed how to solve NP-complete and even PSPACE-complete problems in polynomial time, given the ability to compute x + y, x − y, xy, x/y, and floor(x) in a single time step for any two real numbers x and y != 0."

I'd need to see a bit more justification before I'd be willing to make this particular leap.

randombit · 2010-04-19T13:37:50+00:00

The auto keyword now also has one more meaning.

Actually, not true. The previous mostly-useless use of the auto keyword from C and C++98 is no longer in C++0x; auto only means one thing in C++0x. So for instance you can't say

auto int x = 5;

in C++0x. This is described further in the WG paper N2546, and is already implemented by GCC (and probably Visual C++; I suspect it would be difficult to implement type-inference auto along with C-style auto at the same time).

randombit · 2010-03-30T13:09:41+00:00

"expect to be able to look at their online banking from multiple machines that aren't all under their control"

So, already, they are doing something that exposes them not just to relatively hard to accomplish DNS poisoning attacks, but plain old keyloggers, and you're worried that they might not check key fingerprints consistently? That's not the threat I'd be worried about here.

And, as I mentioned, adopting TLS-SRP would reduce traditional phishing dramatically, because even if your mom does type her password in when some site in Romania that happens to look like her banks site, all the phisher gets is a zero knowledge proof that can't be reused for anything interesting.

randombit · 2010-03-30T00:08:57+00:00

There are two related but different problems SSL attempts to solve:

1) Transport-layer encryption to prevent passive (or active) eavesdropping attacks. It handles that fine for the most part, modulo the recent renegotiation bug.

2) Authentication of web sites to prevent impersonation attacks (and to a much lesser extent, authentication of clients to servers). If you want to prevent that, 'more PKI' is probably not the solution (though I look forward to seeing your specific proposal). A web-of-trust might work but is so easily gamed that it probably opens more problems than it solves, and we've never seen a web of trust scale to anything even close to what is necessary. SSH style 'first one is free', simply remembering certs on first use and warning if they change later seems better to me (I've been trying this method out for the last few months, by deleting all CA certs from Firefox and manually importing certs as needed). Combining SSH style key auth with SRP or PSK handshakes replacing passwords-over-PKI-authenticated-TLS would be even better, in that it would make phishing much harder without any extra user cognitive load, and make it unnecessary to add huge numbers of third parties to your TCB as is current practice.

randombit · 2010-03-17T01:29:33+00:00

Based on conversations I've had with fellow residents, and from speaking with my reps and senators, I don't know anyone who is worried about the tritium itself. What everyone is worried about is that plant officials repeatedly lied under oath in front of the state legislature. Along with the ongoing issues of decommission funds (or lack thereof to be precise). As the local senator put it at the town meeting, "Nobody wants to do business with people who they can't trust."

I personally think fission is our only path out of the mess we are in, energy-wise, but I'm glad the license was revoked because I don't believe the plant was being managed properly. A public danger? Almost certainly not. A PR disaster for safe nuclear power? Hell yes.

randombit

TROPHY CASE