Following is written as a user perspective, not a cryptography
perspective :)
On 8/01/11 1:03 PM, [email protected] wrote:
Hey all,
I'm attempting to create an extensive archive of papers on -graphy and
-analysis, locally stored and broken down by category/hierarchy,
according to my own personal taxonomy. Maybe one day I'll try to
figure out how to annotate their metadata in some way, possibly a
bibtex-to-filename-to-hyperlink mapping, and web apps to ease data
entry.
The most important things I keep quoting (because they are typically the
things that cause the house of cards to collapse...) are these:
Kherchhoffs' 6 laws, especially the 6th, which is dynamite to most
security systems.
Adi Shamir's law, that crypto is typically bypassed.
I know that taxonomies are doomed with such large collections of
unique data, but the web and citeseer and Google Scholar just isn't
doing the job for me, for a variety of reasons that should be obvious
to anyone who has done extensive self-study in a field like this.
I was wondering if anyone had suggestions on conference proceedings,
individual papers, and authors that are worthy of inclusion. Quality
is far more important than quantity - the web already provides the
latter.
For me,
* Specifications for DES and SHA (or similar), because how they
created the black box approach.
* CBC, and similar modes for turning one algorithm into another.
* Selecting Cryptographic Key Sizes, Arjen K. Lenstra and Eric R.
Verheul, PKC2000: p. 446-465, 01/2000, because of how they showed how to
connect black boxes and solve one particular issue, that of numerology.
* NIST's newer approach to PRNGs, because of their (perceived)
success in boxing the RNG field (see disclaimer below).
Each of these represent major steps forward in black box design, which
fundamentally meets the needs of computer scientists to package and
interface with simple sets of requirements.
(In side-comment to cryptographers who feel roughly treated by the
throwaway culture to their fine academic achievements, I point to Adi
Shamir's other law which says "only the simplest ideas get adopted."
Which means, that unless it meets the needs of the computer scientist
for simplicity and clarity, it won't get adopted. Sorry.)
Particularly, I've found cryptanalysis to be spottier in coverage.
I gather this is really a course of study, not a paper or collection of
papers. It's also highly specialised, of limited usefulness outside the
strict field of cryptography.
I recall Schneier had an interesting self-study course in block
cipher cryptanalysis:
http://www.schneier.com/paper-self-study.pdf
good start, I think several colleges have published their courses?
Is there anything else out there like this?
Also, here are three books I wish I had. Do they exist, or will I
have to compile them over the next decade or two?
0) Cryptographic Protocol Design
Something like this:
http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc28.6
However, I think it could be made into an entire book, and covered in far
more detail and less like a "cookbook", but still accessible to security
engineers, as opposed to discrete math postgrads.
I personally think you'll be looking in the wrong place.
The problem (IMNSHO) with the cryptography world view is that they think
that cryptographic protocol design is an art of cryptography. It isn't,
it's an art of computer science.
This art is best described as protocol design augmented with a little
cryptography. In this way, we avoid the bottom-up disease that
typically infects the crypto-dreamers' attempts to solve every perceived
issue with another crypto trick, and add in issues that don't exist
because they enable a new crypto trick to be used...
And, protocol design is firmly a part of computer science. When you get
up into higher layer designs, it becomes architecture ... and eventually
migrates to being business. So even computer scientists don't have the
lock on it :P
On a tangent, my experienced I've coalesced here:
http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html
1) Cryptography: A Study in Failure.
Show cryptosystems and how they were broken or semi-broken, over the
years. That _is_ how we learn, right?
Definately. This is actually embedded in cryptographic pedagogy. Lore
has it that you should spend a decade or so on cryptanalysis of existing
algorithms before attempting to design your own algorithm. This used to
be bedded into computer science when the hacker was a journeyman who's
task it was to break systems in order to understand how to build them
better. Unfortunately, we've lost that culturally these days.
I'm thinking of knapsack, Kerb, e=3 SSL keys, hash length extension,
PKCS#7 padding oracle, and so on.
Note that the system doesn't have to have been designed according to
best practices at the time to be instructive; sometimes how people did
things wrong is far more instructive to an engineer.
Definately.
But, when researching any field in depth, avoid best practices like the
plague.
The use of best practices is a lowest common denominator approach, and
an admission that you yourself really don't understand the field. If
you've admitted you don't understand the field, it is therefore
reasonable for you to copy a cheat sheet from others who also don't
understand the field, but have at least agreed on a simple lowest common
denominator list of hopefully cheap ideas that help.
Psychological
studies show that laws expressed in DO NOT form stick better than
those which say ALWAYS DO.
:-)
For yours truly, I'm intrigued by the way, say, a hash collision can
affect the upper-level algorithm such as SSL certificate verification.
These can be used to teach the difference between preimage-resistance
and collision-resistance properties, for example, and really help an
engineer to understand which he relies upon.
The DO NOT BECAUSE lesson stick even better than those. I imagine
this is the way they teach airplane safety, fire codes, and so on,
and should be the way we teach cryptographic engineering.
2) (CS)PRNG designs
I've never seen these aggregated in one place.
Along those lines, if anyone has ideas on things worthy of inclusion
in those yet-to-be-written books, please LMK.
I've read about NIST's new work, but have yet to research it myself.
My understanding is that they've documented a black box PRNG approach
that is deterministic; so that we can feed in a set of data, and out
comes a set of data which can be tested. This covers the implementation
trap of how to test ones PRNG is doing the right thing.
Then, in implementation terms, we can now separate out the entropy
source from the PRNG. This firewalls the two issues: good entropy from
good implementation. That which is testable is now testable, that which
is "hopeful" like entropy is now small and contained.
This separation into two distinct boxes of different colours is (to me
as a computer scientist) a revelation! Suddenly, RNGs are easy and we
have a methodology to solve all.
Of course I could be talking out of my a**e, I've not really read up on
it, just seen the scuttlebut. E.g., I'm talking about a "best
practices" level of understanding, which really isn't good enough for
proper security architecture :)
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
