Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So, you want to crypto

blog.existentialize.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: So, you want to crypto

#51

Post by biscarch »

sillysaurus2 wrote: post #22
tptacek wrote: post #10

Earlier quoted context omitted.

Two things. First, while "playing around with cryptography" may be the only way to learn it, building cryptographic systems is just about the worst way to learn. Professional cryptographers start by cryptanalyzing targets and use that experience to inform their future designs. On the other hand, veteran implementors who have never taken the time to learn how to break crypto turn out protocols and designs that are rep…

Don't learn by building. You need to learn by breaking. The best way to do this is to do the Matasano crypto challenges. The challenges are designed to get progressively more difficult, and since the goal of most of them is to break something, that means you'll learn how to employ progressively more sophisticated attacks. They're also great for a newbie, because in one challenge you'll implement something that seems…

Today you've convinced me to start on the Matasano challenges. I completed the Stripe CTF from ~ a year ago and I've been looking for something else to try my hand at that would improve my security knowledge.

Re: So, you want to crypto

#52

Post by alinajaf »

haberman wrote: post #50
alinajaf wrote: post #47

Earlier quoted context omitted.

I'm not a cryptography expert either, but I'll give this a crack... In as much as SHA1 is a "cryptographic hash function", Linus isn't taking advantage of a few of it's cryptographic properties in his usage of it in git. It would for example, make no difference to the workings of git if you could reverse-engineer the contents of an object from its SHA1. In the same way, it doesn't matter much to the operation of git…

Thanks for this, you answered my questions thoroughly. I'm not entirely convinced by this though: > [A signed commit] doesn't guarantee anything about the contents of that commit if the repository has been tampered with. I think most people would intuitively expect the signed commit to guarantee the contents of the tree being signed. The idea that you could "git pull" a repo from a compromised machine, verify the sig…

I did a bit of quick reading on this and at first glance my description of how git tagging works appears to be on point, i.e. all it guarantees is that a particular user asserts that tag X points to commit with SHA1 Y.

I'm not sure that it says anywhere in the documentation that it guarantees anything more than that, but I agree that a significant proportion of developers would intuitively expect that the entire content of the tree to be signed rather than just the SHA1.

Re: So, you want to crypto

#53

Post by yeukhon »

tptacek wrote: post #10
phaus wrote: post #3

>Do not let users use your product until it's been vetted. Its OK to let them use it so you can have a large user-base to test with, you just need to explain to them that it isn't proven secure. As in, explicitly tell them that they are under no circumstances to use it with sensitive information. Playing around with cryptography is the only way to learn it, you just have to remember to tell people that playing is exa…

Two things. First, while "playing around with cryptography" may be the only way to learn it, building cryptographic systems is just about the worst way to learn. Professional cryptographers start by cryptanalyzing targets and use that experience to inform their future designs. On the other hand, veteran implementors who have never taken the time to learn how to break crypto turn out protocols and designs that are rep…

I think we should clarify that building can always be breaking. You can implement a script that automate the breaking process (think fuzzer). I can fire up Python interpreter and start playing around with AES encoding with ECB and then figure "shit, ECB is not semantically secure". I can have a damn vulnerable web app and web server. I can implement them, break them and improve them if I am really that dedicated.

I can also learn by reading standard and read how people implement in projects like Firefox or Chromium. And ask questions. I think we should be careful with the meaning of "learn by breaking" because obviously only a handful of people can really break cryto system. And average developers like me are probably better off just learn and break.

Steps like that are probably my way of getting into security engineering and cryto engineering (at some point). I guess I am a different audience, I am not here to break RSA, I am here to learn how real systems are implementing RSA, TLS and see whether those implementations have flaws or not.

Re: So, you want to crypto

#54

Post by lazyjones »

This is a condescending blog post by someone with an (apparently) much weaker crypto background than the telegram people he is ranting about. Of course it's much easier to post something like that than it is to actually get a rock-solid implementation at the first attempt - and we can safely assume that the telegram people do not need such advice.

Would not read again.

Re: So, you want to crypto

#55

Post by milhous »

kbhomes wrote: post #27
milhous wrote: post #26

I'm taking an Intro to Crypto course this spring. What's interesting is that it's offered through the Math department, and assumed it was a CS class. We'll be using this text: http://www.amazon.com/Introduction-Cryptography-Coding-Theor... Is this any good? Apparently a best seller in the "Software Coding Theory" category on Amazon.

I had this same textbook for the Crypto course I just completed this semester. It's a very good textbook, in my opinion, as the descriptions and examples are really informative. Usually if I couldn't get the material through my professor's lectures, it was sufficient to look it up in the book. However, we did only briefly touch on cryptographic hashes and only a little on Legendre and Jacobi symbols, and not at all o…

Thanks everyone for their reviews. Glad to hear this isn't a POS text.

I'm taking this at Millersville University as a once-a-week, 3 hour evening course. I'm a Physics and CS major, and am taking it as an elective to get a Math minor.

With all the NSA and crypto news these days, it sounds like a great time to learn about the fundamentals of crypto. And I'm curious if there will be actual programming involved because to my knowledge, there aren't any prereqs for it, not even an intro to programming course.

Re: So, you want to crypto

#56

Post by DennisP »

Nursie wrote: post #49

Ok so I do want to crypto and (to the best of my ability) I already do. I follow best practices, read about the subject matter, did coursera's crypto 1 (and where the hell is pt2? 1 was awesome!). I use established algorithms and I use, well audited implementations etc etc. where available. I have a question about MACs. We're using HMAC based on SHA256 with 32-byte keys on our new system, but our security architect o…

Part 1 begins again in January and part 2 begins right after it's done.

Re: So, you want to crypto

#57

Post by daeken »

phaus wrote: post #21
tptacek wrote: post #10

Earlier quoted context omitted.

Two things. First, while "playing around with cryptography" may be the only way to learn it, building cryptographic systems is just about the worst way to learn. Professional cryptographers start by cryptanalyzing targets and use that experience to inform their future designs. On the other hand, veteran implementors who have never taken the time to learn how to break crypto turn out protocols and designs that are rep…

I get that you need to learn how to break software as a major part of the learning process. I also understand that a broken system often can't be fixed, and that if your system breaks you might have to start from scratch. But does one go from becoming an expert at breaking systems to automatically churning out a secure cryptographic system? Or does one become an expert at breaking and then build a bunch of flawed cry…

> But does one go from becoming an expert at breaking systems to automatically churning out a secure cryptographic system? Or does one become an expert at breaking and then build a bunch of flawed crypto systems, as the learning process continues?

Both and neither. Once you get really good at breaking cryptosystems, designing them looks very similar. You start with best practices: use sane primitives (or thoroughly vetted components, preferably!) and put them together in known, simple (simple is key) ways. Then you put on your breaking hat and you attempt to violate every constraint. If you find a flaw, then you iterate or redesign. Once you are happy with it, you start showing it to other crypto breakers, until they're happy with it too.

At this point, you have something that would withstand most basic attacks, and you might be ready to put it out into the world. It's still not battle-hardened and ready for uberconfidential data, but it's in a better state than most cryptosystems. As more and more people look at it without owning it, its trustworthiness goes up, and the risk goes down.

Secure cryptosystems don't pop out of nothing; they're iterative, but not in the "I should do a Show HN" sense. It's iterative like writing a poem -- you don't release it one line at a time.

Re: So, you want to crypto

#58

Post by sidcool »

The author seems quite pissed at the state of crypto in the world, and he's definitely trying to help. I like the general language of the post. Good work and keep it up!

Re: So, you want to crypto

#59

Post by arghnoname »

milhous wrote: post #26

I'm taking an Intro to Crypto course this spring. What's interesting is that it's offered through the Math department, and assumed it was a CS class. We'll be using this text: http://www.amazon.com/Introduction-Cryptography-Coding-Theor... Is this any good? Apparently a best seller in the "Software Coding Theory" category on Amazon.

Dr. Washington (one of the authors, I believe the other was a grad student of his) seems to be a really decent guy and cares a lot about teaching. He goes to middle and high schools fairly regularly to introduce kids on these topics.

That concern is reflected in the textbook and his course. It's a very approachable treatment and it seems like a lot of emphasis is placed on making it fun.

The downside to a math listed CS crypto course (as it is where Washington teaches) is that there may be less emphasis on flaws that occur in actual real word implementations. A professor in the CS department also teaches crypto at Maryland and actually uses a different book (one he wrote). My understanding is that there is a bit more attention paid to implementation there, but that's coming second-hand.

Re: So, you want to crypto

#60

Post by arghnoname »

Nursie wrote: post #49

Ok so I do want to crypto and (to the best of my ability) I already do. I follow best practices, read about the subject matter, did coursera's crypto 1 (and where the hell is pt2? 1 was awesome!). I use established algorithms and I use, well audited implementations etc etc. where available. I have a question about MACs. We're using HMAC based on SHA256 with 32-byte keys on our new system, but our security architect o…

It definitely does reduce the strength of the MAC, but it is okay if your security requirements require it. Keeping in mind that some generic birthday attacks already reduce HMAC strength to n/2 bits (IIRC), and SHA-256 has you down to 128 bits of security (with an online attack though).

Truncation is mentioned in RFC 2104. I quote:

5. Truncated output

   A well-known practice with message authentication codes is to
   truncate the output of the MAC and output only part of the bits
   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
   analytical advantages of truncating the output of hash-based MAC
   functions. The results in this area are not absolute as for the
   overall security advantages of truncation. It has advantages (less
   information on the hash result available to an attacker) and
   disadvantages (less bits to predict for the attacker).
   Applications of HMAC can choose to truncate the output of HMAC by
   outputting the t leftmost bits of the HMAC computation for some
   parameter t (namely, the computation is carried in the normal way
   as defined in section 2 above but the end result is truncated to t
   bits). We recommend that the output length t be not less than half
   the length of the hash output (to match the birthday attack bound)
   and not less than 80 bits (a suitable lower bound on the number of
   bits that need to be predicted by an attacker).  We propose
   denoting a realization of HMAC that uses a hash function H with t
   bits of output as HMAC-H-t. For example, HMAC-SHA1-80 denotes HMAC
   computed using the SHA-1 function and with the output truncated to
   80 bits.  (If the parameter t is not specified, e.g. HMAC-MD5, then
   it is assumed that all the bits of the hash are output.)
Post reply on HN