NCC Group Cryptoservices Blog
cryptoservices.github.io · Company blog · on HN since 2014
The cryptography team at NCC Group writes about cryptography, security audits, Bitcoin, and low-level vulnerabilities.
What HN saysHN commenters cite it for posts on undefined behavior in C, Bitcoin chain consensus, and hash-based signatures, and its team posts hiring notices there.
19HN people shared it
9linked it in comments
12stories submitted
437story points
2 years agolast shared
2014people per year2026
Most-shared posts
- 1Confidential Transactions from Basic Principles5 people · 149 points · first shared 2017 · 12 comments on HN
- 2Code Execution in Spite of BitLocker4 people · 44 points · first shared 2014 · discussion on HN
- 3Undefined Behavior Is Really Undefined3 people · 94 points · first shared 2018 · 107 comments on HN
- 4OpenSSL Audit2 people · 145 points · first shared 2015 · 79 comments on HN
- 5Code Execution in Spite of BitLocker1 people · 2 points · first shared 2014 · discussion on HN
- 6Bitcoin Orphan Transactions and CVE-2012-37891 people · 2 points · first shared 2018 · discussion on HN
- 7Lives of Bleichenbacher's CAT: New Cache ATtacks on TLS Implementations1 people · 1 points · first shared 2019 · discussion on HN
- 8One time signatures1 people · first shared 2021
- 9Challenges1 people · first shared 2016
- 10Openssl audit…1 people · first shared 2015
- 11Bitcoin length weight confusion1 people · first shared 2021
- 12Falcon implementation1 people · first shared 2019
What HN people wrote when they linked it
perl4ever · 2021-09-29
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/bitco…
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.
Labo333 · 2021-06-06
Neat! This is actually the fundation of hash-based signatures [1] that are (for the moment believed to be) quantum resistant.
I recommend this awesome series of blog posts to learn more about hash-based signatures [2] (Merkle Trees are discussed in the third article).
Finally, a shameless plug of a repo [3] where I implement Lamport and Winternitz's schemes for one-time signatures and Merkle trees for many-times signatures. I make use of the C reference implementation of SHAKE-128, which is currently considered to be the most secure hash algorithm from NIST.
[1]: https://en.wikipedia.org/wiki/Hash-based_cryptography
[2]: https://cryptoservices.github.io/quantum/2015/12/04/one-time-signature…
[3]: https://github.com/louisabraham/hash-crypto
MaxBarraclough · 2020-09-24
> 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.htm…
[2] https://blog.regehr.org/archives/759
[3] https://blog.regehr.org/archives/767
baby · 2016-11-01
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: [email protected] !
josephcsible · 2022-04-09
In case it's not obvious how this can happen, it's because the promotion rules can turn them into signed ints, and if they're big enough the product can overflow that. For more details, see https://cryptoservices.github.io/fde/2018/11/30/undefined-behavior.htm…
mtlynch · 2021-10-05
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-spit…
lawnchair_larry · 2015-02-18
Oh, the diffuser matters a lot actually. Your former colleagues (I think?) proved this by blindly popping calc on a bitlocker-protected Windows 8.1!
https://cryptoservices.github.io/fde/2014/12/08/code-execution-in-spit…
With the diffuser, we have ~9 years of conjecture and speculation, with no one overly certain that attacks are possible. Without it, we have calc.exe fairly quickly after someone got the idea to try. You can't say these are roughly the same in practical terms.
aleks227 · 2019-11-01
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/…
- 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
bonjarber · 2015-04-30
>"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…