The cryptography team at NCC Group writes about cryptography, security audits, Bitcoin, and low-level vulnerabilities.
HN commenters cite it for posts on undefined behavior in C, Bitcoin chain consensus, and hash-based signatures, and its team posts hiring notices there.
>"this system is even larger than in the past and as such slip-ups are only going to increase.”
Yes, the system is certainly larger (as is the internet as a whole) and slip-ups are natural. Luckily these 'slip ups' are typically simple things like certs expiring or supporting outdated cipher suites. These are just minor configuration fixes that things like Lets Encrypt aim to fix (both distribution and configuration of TLS). The thing is, even the worst 'slip ups' don't make you any more insecure than only supporting HTTP. _Any_ amount of TLS is better than none. That is a weak argument to start with.
>"SSL is bloody expensive compared to not doing it."
No it’s not. Certs are not expensive (another thing improved by Let’s Encrypt). This opinion exists from people spreading these kinds of rumors. It’s 2015 and the minor difference in processing power is negligible. If your web hosting can’t handle the difference in processing costs, you need to look for a better hosting platform.
>"Not only does that mean that you are downloading a really big certificate, but also that the SSL encryption is a bit of a lie for you as a user.”
'Really big certificate' when has this been an issue for anyone ever? A CDN providing SSL is still better than no SSL. That "lie" _still_ protects the user at their host->Local Router->ISP->CDN. This is massive value not offered via just HTTP.
>"The cost of deploying SSL should not be underestimated, and forcing SSL on people out of principle should…
Cryptography Services @ NCC Group (formerly Matasano Security, iSEC Partners, and Intrepidus Group) - Atlanta, Austin, Chicago, New York, San Francisco, Seattle, and Sunnyvale, CA
INTERNS / VISA
The Cryptography Services team of NCC Group is looking for a summer 2017 intern!
We are looking for you if you’re into cryptography and security! The internship would allow you to follow consultants on the job as well as lead your own research project.
Who are we? We are consultants! Big companies come to us and ask us to hack their stuff (legally), review their code and advise on their design. If we’re not doing that, we spend our time reading papers, researching, attending conferences, giving talks and teaching classes, ... whatever floats our boat. Not one week is like the other! If you’ve spent some time doing cryptopals challenges you will probably like what we are doing.
We can’t say much about who are the clients we work for, except for the public audits we sometimes do. For example we’ve performed public audits for TrueCrypt, OpenSSL, Let’s Encrypt, Docker and more recently Zcash.
I was myself the first intern of Cryptography Services and I’d be happy to answer any question you might have =)
If you're interested, take a look at the challenges we have in place: http://cryptoservices.github.io/challenges/
You can also directly contact me here: david.wong@nccgroup.trust !
Cryptography Services @ NCC Group | NYC, SF, Chicago, Seattle, Austin, Waterloo (Ontario) | ONSITE | INTERNS
NCC Group Crypto Services is hiring interns for summer 2020! We're a small team auditing applied crypto and doing research in the field. If you like cryptography and security, and would like to pursue a research project in any of the applied crypto areas, such as (but not limited to):
- cryptographic implementations (cryptographic protocols or primitives block ciphers, elliptic cures, hash functions, lightweight crypto, post-quantum crypto)
- cryptocurrencies (payment channel security, audit of novel consensus algorithms, privacy preserving coin implementations)
- audits of existing cryptographic software
Some previous work samples done by our crypto interns:
- Implementing Optimized Cryptography for Embedded Systems https://cryptoservices.github.io/post-quantum/cryptography/2019/10/21/falcon-implementation.html
- nQUIC: Noise-Based QUIC Packet Protection https://eprint.iacr.org/2019/028.pdf
- Confidential Transactions from Basic Principles https://cryptoservices.github.io/cryptography/2017/07/21/Sigs.html
If you are interested, please reach out! aleksandar.kircanski_at_nccgroup_com
> Especially is not something to be afraid of.
Disagree. UB in C can mean your program silently going off the rails in a way that isn't possible in many other languages. UB really can manifest in bizarre and scary ways on real platforms. [0][1][2][3] If it isn't manifesting that way in your case, that's just good fortune.
> I still have to find a bug or fail a test because some strange UD
I should hope your safety-critical code is not permitted to contain known instances of unintended undefined behaviour. (There can be exceptions where UB is truly intended. JIT compilation always relies on UB, for instance, not that this would apply to safety-critical code.)
If your program contains undefined behaviour, that means that at best, it works by coincidence. Safety-critical code should not work by coincidence, it should be correct by construction (to steal a term from the formal methods world).
Also, it's UB, not UD.
[0] https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633
[1] https://cryptoservices.github.io/fde/2018/11/30/undefined-behavior.html
[2] https://blog.regehr.org/archives/759
[3] https://blog.regehr.org/archives/767
This is a little silly because this assumes that BitLocker is configured for TPM-only rather than requiring a TPM PIN/password.
If there's a TPM password, this attack becomes infeasible because the TPM won't release the keys without the password. And you generally can't brute force the TPM without triggering the hardware lockout.
The company's IT department can require TPM+Password in Group Policy so that every system in the organization uses TPM+Password, but I guess you could have a stubborn CEO who demands a less secure policy.
As of Windows 8, it was possible to replace ciphertext on a BitLocker-encrypted drive to compromise known Windows binaries.[0] This would allow the attacker to take control of the system on next boot, though I don't know if those attacks are still practical.
[0] https://cryptoservices.github.io/fde/2014/12/08/code-execution-in-spite-of-bitlocker.html
But which chain? From what I read, it's very important to distinguish between the true chain which full nodes can come to consensus on based on proof of work, and a possible attacker chain which is longer, but low effort.
https://cryptoservices.github.io/blockchain/consensus/2019/05/21/bitcoin-length-weight-confusion.html
And I believe I've read that, when you aren't running a full node, you have to just assume the longest chain is the right one. I mean, all that data is the chain, right? If you don't process it, you have to assume other nodes are trustworthy.
What you are saying about complete control sounds to me like if I said I have complete control over my bank account, in the sense nobody can guess my password, but maybe the bank is fake and I'm not even trying to check.