in cont to the discussion re implication on practice

[עודד גולדרייך‎]

Let me start by re-iterating my first position, which is that
practitionaires
should state clearly what they assume about the cryptographic tools
and/or schemes they use. I recommend that the specification takes
the form of clear assumptions regarduing the *type* of actions that
adversaries can take (incl possible limits on computational
resources).

Secondly, I'd advice to prefer simply stated assumptions regarding
simple
primitives over complicated assumptions regarding complex primitives
(let alone complex systems). For example, I prefer assuming that a
function is one-way over assuming that this function is a pseudorandom
generator, let alone that an "encryption scheme" is secure or that
a protocol satisfies a specific functionality....

The course may be viewed as showing how simple assumptions
(e.g., one-way functions) can be used to construct more complicated
primitives (like pseudorandom generators and encryption schemes...),
let alone construct systems that provide a host of desired
functionalities.
Note that I use the words "can be used", hinting that these are
feasibility
results, whereas in practice one may wish more efficient solutions.
Still, the message is that in many cases there seem to be no barrier
between relatively simple assumptions and highly complex
cryptosystems;
that is, the former can be *trasformed* into the latter.