251–260 of 409 posts
I have read the article and I still don't understand what was the purpose of such a project. What's wrong with ZIP or 7-Zip + AES encryption? Or GPG with a GUI? Or any other existing tool that's already stable and multi-platform?
I've browsed through the code and i don't see why say it is not good in MT setting... an first view the code is completely reentrant...
Another thought: i strongly suspect that inlining these store_le... and load_le... function will show pretty significant performance boost
Earlier quoted context omitted.
You find it fantastically unrealistic that a vulnerability could be found for a well known and widely used encryption method?
Depending on the algorithm: yes. I'm not saying all algorihms that are widely used and well known are extremely unlikely to be broken. I would happily bet $10,000 that AES will not be broken in the next ten years. I'd make the same bet for several hash functions. And as a corollary to this point: I think it's incredibly foolish to try and combat the threat of an encryption algorithm being broken by double encrypting…
What are you talking about: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
You'd lose the bet so hard. Don't take anything for granted. Even the most supposedly secure and widely used primitives should be scrutinized and are subjects to constant attacks.
It's interesting that Frama-C was mentioned. I have been playing with it the last few months and would love to hear exactly how it was used. I've read through a lot of the documentation but haven't found many examples of it being used
Note that this is the initial stage of using Frama-C. The next step would probably include writing some specifications for functional behavior (in ACSL), and then using the WP plug-in (based on weakest precondition calculus) to prove those specifications, providing much stronger guarantees.
A few Frama-C case studies are on Github (https://github.com/Frama-C/open-source-case-studies), including an old release of Monocypher, but they constitute mostly a initial parametrization of the EVA plug-in. Most advanced users of Frama-C apply it on industrial code that is not available, but academic users regularly publish papers with case studies (searching "frama-c" on Google Scholar gives good results).
Earlier quoted context omitted.
> a network protocol is not designed to be error-proof in an intentionally antagonistic environment Err, really? That may be the case sometimes. Also these days many things can be antagonistic: anything online is exposed to adversaries. So is anything that routinely reads untrusted input on everyone's computer (like a video player, or a pdf reader). Thinking of the sheer amount of potentially vulnerable code out ther…
But is the code you're speaking of the security-specific code, or the network-specific code? If you attack a networking protocol, what are you attacking if not the associated cryptography? A networking protocol without any cryptography doesn't really need to be attacked because it's already wide open. You introduce the confidentiality, authentication and integrity (which is really just going to be part of the authent…
Anything that accepts data from potentially-malicious sources is security-critical if it's itself privileged or produces data/events that go to something else privileged. Such analysis is usually used to determine the "Trusted Computing Base" (TCB) of a system that encompasses everything that might be used to break the security policy. All people who do real, security engineering keep it in mind, minimize it, strengthen it, and document what's left.
Here's an example from high-assurance field of what that looks like where they prototype an architecture for VPN's that minimizes TCB of key components:
https://os.inf.tu-dresden.de/mikrosina/dach2005.pdf
Far as qualifying the TCB, the seL4 team's What is Proved and What is Assumed is a great illustration of keeping it real about the security claims:
https://sel4.systems/Info/FAQ/proof.pml
Also shows their TCB is a lot bigger than their tiny kernel. Fortunately, there's been high-assurance developments to solve most of those things. I've seen robust, networking stacks but don't think they're high-assurance yet. If they're complex and done in C, here be dragons.
Earlier quoted context omitted.
Again I feel the need to reiterate that the rule only needs to apply to those it needs explaining to. Ie nobody who is smart enough to roll their library would not do so for a production system without it having undergone rigorous testing first. Sure we might write hobby projects (I've written my own encryption ciphers for fun) but that's very different from actually using said cipher on live and/or business critical…
I agree with what you're saying in general, that people should not write a crypto library unless they have a strong need to and are going to have it thoroughly audited. > Simply put, the rule is there to remind people that rolling your own crypto libraries is dangerous. It's not meant to be taken literally to the daft extremes that yourself and a few others on here have. My problem is that this nuance is not present…
Earlier quoted context omitted.
No, it is targeting both. I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks, I haven't looked to see if there is any sensitive memory scrubbing. Of the bugs listed most are performance bugs by someone who doesn't know C very well yet have they done the things actually!my required in a crypto library like attempting to make sure all branches are the same instruction…
> I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks, Oh come on, the chosen primitives are all designed for easy immunity against timing attacks. I haven't verified this formally, but I basically ripped off safe designs, and I tried to be careful about avoiding secret dependant branches and indices. > I haven't looked to see if there is any sensitive memory scrubbi…
I would like to clarify: The thing that I said was "table stakes" for implementing cryptography was passing the algorithm test vectors , which this author's previous post claimed as a security feature. If you're unfamiliar with the concept, a test vector is a series of strings and intermediate values used to ensure that your (say) OCB3 is the same as everyone else's OCB3. Had he asked, I'd further claim that not havi…
This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that "you just have to know" is not so easy to find. The courteous thing to do when mentioning something that "you just have to know" but which is not easy to find is to provide a pointer or a short in-line explanation. When you don't do that you leave your reader with no choice but to publicly expose their ignorance of this purportedly crucial knowledge by asking, which I will now proceed to do as a public service: What the hell is a carry propagation bug? Where do you look for them? And what is their impact?
And while we're at it, what are "table stakes"?
I am terrified that I do not consider myself competent enough to write a crypto library, and yet there isn't a single mention - in this article, nor at the time of writing the comments here on Hacker News - of many of the pitfalls I know to avoid when undertaking such an endeavour. There is even a list of "you have to do A, B, C, and that's about it" that is missing some major - well known, even! - items. I know "don…
I would like to clarify: The thing that I said was "table stakes" for implementing cryptography was passing the algorithm test vectors , which this author's previous post claimed as a security feature. If you're unfamiliar with the concept, a test vector is a series of strings and intermediate values used to ensure that your (say) OCB3 is the same as everyone else's OCB3. Had he asked, I'd further claim that not havi…
> You just have to know what a carry propagation bug is This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that…