Although I might pretend very well that I know a thing about networks or security and it might help me pass an interview or fix a bug, I don't really feel I'm fooling anyone.
I'm looking for laymen explanation of current network security concepts and solutions. The information is scattered around and I didn't find a resource for "dummies" like me (e.g experienced Java developers that can speak the jargon but have no real clue what it means).
Topics I have a weak notion about and want to understand better as a Java developer:
PGP
Public / Private keys
RSA / DES
SSL and 2 way SSL (keystore / trustore)
Protecting against Man in the middle fraud
Digital Signature and Certificates
Is there a resource out there that really explains it in a way that doesn't require a Cisco certificate / Linux lingo / know what is subnet masking or other plumbing skills?
The book Cryptography Engineering by Ferguson, Schneier, and Kohno might be something that would get you a decent way down the road to understanding the topics you listed. I read the first version of this book (Practical Cryptography) and found it to be quite good. For example, I thought the descriptions of public key/private key cryptography to be reasonably straightforward to understand.
It might not explicitly describe the specific terms in all cases that you are asking about. For example, I just looked in the index of my copy of Practical Cryptography and do not see the terms "keystore" and "truststore", but the first google hit I clicked on for those provided a definition in language I understood (largely because I read the book).
I also own Applied Cryptography mentioned by Aidan Cully, and I think it is also a very good book and certainly worth owning. However I tend to think of it more as a reference book (although somewhat dated - the copyright is 1996). In terms of real-word advice, though, I think the original title of the newer book Practical Cryptography was right on. The book seems, well, practical.
Schneier's Applied Cryptography is how I learned most of what I know. I haven't read it, but expect Ross Anderson's Security Engineering would also be a good resource.
Priactical UNIX and Internet Security will cover a lot of that stuff and give you a basic UNIX background. Also, if you have extra time Academic Earth has free video lectures from top universities.
Related
Are there any open-source implementations of NTRU-KE (Preferably in Java or C#) out there that I can use as a reference for implementing it in a different language?
The implementations listed on the Wikipedia page for NTRUEncrypt don't have it included, and there's a paper covering the algorithm here but the language is a bit too technical for me to be able to understand it fully.
Future readers, please prove me wrong (and post your own answer).
Given it is pretty new (November 2013) there probably aren't any implementations at all. Even the authors of the paper might not have implemented it themselves (you could ask them though). But as far as I can tell the protocol only uses operations that would have to be included in NTRUEncrypt implementations anyway. So it shouldn't be to difficult to write one yourself on top of an existing NTRU library. You can ask specific questions on the protocol here or on https://crypto.stackexchange.com. Probably you should try to understand the basics of NTRUEncrypt first, though.
I am looking for tools (preferably free) to practice various cryptoanalysis and cryptography techniques. Something along the lines of following two online tools but with more techniques.
http://www.cryptool-online.org/index.php?option=com_content&view=article&id=55&Itemid=53&lang=en
http://www.simonsingh.net/The_Black_Chamber/letterfrequencies.html
Any suggestions would be very welcome.
Thanks,
Ambi.
The Matasano Crypto Challenges are an excellent learning resource for cryptography.
We've built a collection of 48 exercises that demonstrate attacks on
real-world crypto.
This is a different way to learn about crypto than taking a class or
reading a book. We give you problems to solve. They're derived from
weaknesses in real-world systems and modern cryptographic
constructions. We give you enough info to learn about the underlying
crypto concepts yourself. When you're finished, you'll not only have
learned a good deal about how cryptosystems are built, but you'll also
understand how they're attacked.
The first couple of sets may seem a bit too easy for someone acquainted with cryptography, but the challenges quickly get more tricky and advanced.
I don't know much about the heavy math behind cryptosystems, I get stuck when it gets bad with the Z/nZ algebra, and sometimes with all these exponent of exponents. It's not I don't like it, it's just that the information you find on the web are not easy to follow blindly.
I was wondering: how reliable can a algorithm be when it encodes a message into plain binary. If my algorithm is arbitrary and known only to me, how can a cryptanalist study an encrypted file and decrypt it, with or without having the decoded file ?
I'm thinking about not using ASCII text to code my message, and I have some ideas to make this algorithm/program.
Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him, but how does he do then ?
I don't know if I understanded well, but a CS teacher once told me that codes are harder to crack that crypted ciphers.
What do you think ?
Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him...
What about:
Attacking an untested self written algorithm with no real research is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with, is a well known and proofed one, that has been correctly used....
In short, DO NOT roll your own cryptography unless you're an expert, no unless you're part of an expert group in that field.
Nintendo failed when they implemented RSA on their own in the Wii, Sony failed too when using it in the PS3 (they pretty much used XKCD's random number function for M...)
And you really think you can win by using security by obscurity?
PS: That doesn't mean that you should take the Wikipedia entry on RSA and roll you own implementation from that one (that's exactly were Sony and Big-N failed), no use a tested, open source implementation.
You seem to be using two words interchangeably but remember that Encoding is Not Encryption
When the attacker has no idea which algorithm you used and it is safe, cryptoanalyst has a hard job. So it is unimportant if you use AES or your own cipher as long as it is as strong and safe as AES. Here is the but. Cryptography is a bit demanding and therefore you have many ways to shoot yourself in a foot without knowing it. I would suggest using standard algorithms, maybe with some safe variations.
Common wisdom is that you should not build your own algorithms, and especially not rely on these algorithms remaining secret.
The conceptual reason is that good encryption is about quantified confidentiality. We do not want our secrets to get cracked, but in a more precise way we want to be able to tell how much it would cost to crack our secrets (and hopefully show that the cost is way too high to be envisioned by any entity on Earth). This is the real advance which occurred a few years after World War II: to understand the distinction between key and algorithm. The key concentrates the secret. The algorithm becomes the implementation.
Since the implementation is, well, implemented, it exists as some code or a device, which is tangible and stored even when it is not used. Keeping an implementation secret requires keeping track of the hard disk on which the code resides at all times. If the attacker sees the binary code, he may be able to reverse-engineer it, something which depends on his wits and patience. The point here is that it is very difficult to be able to say: "it costs X dollars to recover a description of the algorithm".
On the other hand, the key is short. It can be stored safely much more easily; e.g. you could memorize it, and avoid committing it to any permanent storage device. You then have to worry about your key only at times when you use it (and not when you do not, e.g. in the middle of the night, when you sleep). The number of possible keys is a simple mathematical problem. You can easily and accurately estimate the average cost of enumerating the possible keys until your key is found. The key is a sturdy foundation for quantified security.
So you should not roll your own algorithms because then you do not know how much security you get.
Also, most people who rolled their own algorithms found out, usually the hard way, that they did not get much security at all. Designing a good encryption algorithm is hard, because it cannot be automatically tested. Your code may run, and properly decrypt data that it encrypted, but it tells you nothing about how secure the algorithm is. The design of the AES was the result of a process which took several years and involved hundreds of skilled cryptographers (most of whom had a PhD and years of experience in academic research on symmetric encryption). That a lone developer could do as well, let alone better, in the secrecy of his own workshop, looks kind of... implausible.
The biggest part of your strategy is called "security through obscurity." You're making the gamble that, since nobody knows the precise details of your little variation on an idea, they won't be able to figure it out.
I'm not a security expert, but I can tell you that you probably won't come up with something incredibly new. Cryptography has been studied by people for millenia and your idea is highly unlikely to be original. Even if you're a relatively good programmer and code something really tricky, the question will come down to who you're up against. If you're just trying to protect your data from your kid sister, then it will probably be fine. On the other hand, if you're using it to send credit card numbers across the internet, then you're doomed to fail. It will be analysed in ways you didn't think of or don't know, and ultimately cracked.
Another way to think of it: algorithms like AES have been extensively studied by professionals in the field and its level of security is pretty well understood. Anything you come up with by yourself will not have the benefit of having been attacked by the best and brightest minds out there. You will have almost no idea of how good it actually is until people start reporting identity theft.
It's very easy to explain NoSQL from high level view - it is basically "key-value" storage. Of course with thousand minor and important things, but in general it's just key value storage.
What's the best way to explain Hadoop and Map/Reduce?
May be some "real world" example which can be easy to give an compare for even newbies? Thanks!
I recently found this great article describing Map Reduce :
I’ve been planning on writing about
the Google’s MapReduce algorithm for
some time but I couldn’t find a good
practical example. Then we had a
Northwest C++ Users Group presentation
by Steve Yegge and a followup
discussion and beers, and I had a
little epiphany. Steve was talking
about, among other things, the build
process. And that’s just a bunch of
algorithms that are perfect for
explaining MapReduce.
The code examples are in C++, but the content is really language agnostic.
Here's a great tutorial on map/reduce in general, explaining the background, basics and data flow. I'm finding it useful to explain Google's App Engine implementation as well.
http://developer.yahoo.com/hadoop/tutorial/module4.html
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I know you should never make your own cryptography, whether it is a cipher or hashing algorithm or even a secure pseudo random number generator these things I developed over a long standardisation process. However what I'm looking for quotes or good point in order to quickly describe/argue this to the occasional developer that decides to write their own cryptographic algorithm.
You can tell this developer that existing algorithms such as AES have been analyzed by countless experts in cryptanalysis (which would certainly involve an advanced understanding of numbers and computer science) and tested in competitions, where there's a real incentive for creating secure algorithms.
You can also tell this developer that just because an algorithm is popular, it doesn't mean that it's insecure (if that was this developer's rationale). Just because lots of people know how door locks work doesn't make door locks insecure, nor is it a good justification for people to create their own door locks.
For a real world example, see this TDWTF article about Nintendo's bug in the Wii's security functions. Nintendo (a big, well-known company with plenty of programmers) tried to implement an existing algorithm and managed to screw that up. What makes this developer think that he/she has the l33t h4x0r skills to write a new, secure algorithm?
Anyone who thinks they have devised an
unbreakable encryption scheme either
is an incredibly rare genius or is
naive and inexperienced.
Unfortunately, I sometimes have to
deal with would-be cryptographers who
want to make "improvements" to PGP by
adding encryption algorithms of their
own design.
I remember a conversation in 1991 with
Brian Snow, a highly placed senior
cryptographer with the NSA. He said he
would never trust an encryption
algorithm designed by someone who had
not "earned their bones" by first
spending a lot of time cracking codes.
That made a lot of sense. I observed
that practically no one in the
commercial world of cryptography
qualifies under this criterion. "Yes,"
he said with a self-assured smile,
"And that makes our job at NSA so much
easier." A chilling thought. I didn't
qualify either.
Philip Zimmermann, Beware of Snake Oil
Just tell them that unless they have several decades of experience in math, computer science and cryptography, and then a few years to design the algorithm, it is highly unlikely that they will be able to produce a better cryptographic encryption scheme than the ones that already are in widespread use, all of which have been worked on by a lot of people, many of which almost definitely have the background I described above.
Point the non-believer to these URL's:
Security Pitfalls in Cryptography By Bruce Schneier
Cryptography from princeton.edu
Homebrew Cryptography
Wikipedia Article on Cryptanalysis
As others have mentioned, you can use just about anything that Bruce Schneier says as a quote! He frequently mentions that anyone can create a cipher that he or she cannot break. He's expounded on this in detail but I can't find the article atm, but here's some essays of his that touch on this area:
Why the Worst Cryptography is in the Systems that Pass Initial Analysis
So, You Want to be a Cryptographer
yes thats true.. but all in all encryption is scrambling and substitution. so you can make your own cipher easily.. scramble your text using basic XOR and use a dictionary for substitute.
http://en.wikipedia.org/wiki/XOR_cipher
Hope this can help
Regards.