11–20 of 148 posts
Also here is is a Dan Boneh cryptography playlist https://www.youtube.com/playlist?list=PL9oqNDMzcMClAPkwrn5dm...
http://crypto.stanford.edu/~dabo/cs255/syllabus.html
(Disclosure, I took the class a few years ago)
I wonder if there shouldn't be a software engineering class where people try to set up a secure web app, with their own homegrown algorithms and protocols, which is then attacked by a tiger team which includes a conspirator on the inside? Perhaps there are such classes now.
When I was taking Aikido, there was a day when the sensei was going through all of our techniques and showed how the uke (initiator of the attack, receiver of the technique) could turn things around on the tori . (receiver of the attack, initiator of the technique) It seemed like there were a half dozen ways each that a technique could go seriously wrong, and that many of them didn't require much skill, only determin…
With everything in Crypto I have to wonder: Is the information correct? I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited.
Well this is step 0 in cryptography engineering: You don't implement primitives. Use reviewed components providing primitives and implement your protocol on top of that. Step -1 is to not design your protocol, but use a reviewed protocol and implement that. Finally, step -2 is to not implement a protocol, but rather use a reviewed implementation of a fitting protocol.
This isn't sarcasm and I don't mean to attack you.
When I was taking Aikido, there was a day when the sensei was going through all of our techniques and showed how the uke (initiator of the attack, receiver of the technique) could turn things around on the tori . (receiver of the attack, initiator of the technique) It seemed like there were a half dozen ways each that a technique could go seriously wrong, and that many of them didn't require much skill, only determin…
With everything in Crypto I have to wonder: Is the information correct? I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited.
Well, one benefit of wide exposure (like here on HN) is that if it was wrong, somebody would be bound to come along and point it out. FWIW, I consider myself pretty well-versed on cryptography and although I haven't gone over this book with a fine-toothed comb (yet!), it looks very, very accurate to me.
I wouldn't expect that subtle implementation errors or even protocol flaws would get noticed on any news site, or even by contributors / co-developers or whatever.
When I was taking Aikido, there was a day when the sensei was going through all of our techniques and showed how the uke (initiator of the attack, receiver of the technique) could turn things around on the tori . (receiver of the attack, initiator of the technique) It seemed like there were a half dozen ways each that a technique could go seriously wrong, and that many of them didn't require much skill, only determin…
What would be the purpose of such a class? If the point is to show that rolling your own security is bad, it seems like having an inside man would just help leave people convinced that they could have succeeded if only it weren't for that other guy.
E.g. even if RSA is (currenly) safe, as well as its primitives and common configuration... rolling your own implementation will probably be subject to timing attacks.
With everything in Crypto I have to wonder: Is the information correct? I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited.
With everything in Crypto I have to wonder: Is the information correct? I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited.
> I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited. Well this is step 0 in cryptography engineering: You don't implement primitives. Use reviewed components providing primitives and implement your protocol on top of that. Step -1 is to not design y…
Earlier quoted context omitted.
> I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited. Well this is step 0 in cryptography engineering: You don't implement primitives. Use reviewed components providing primitives and implement your protocol on top of that. Step -1 is to not design y…
There's a difficult rabbithole here - eventually you have to draw a line and decide to trust someone . Otherwise it's just layer after layer of paranoia until you implode in a puff of Philip Dick :)