On Thu, 8 Aug 2002, AARG!Anonymous wrote:
It's likely that only a limited number of compiler configurations would
be in common use, and signatures on the executables produced by each of
those could be provided. Then all the app writer has to do is to tell
people, get compiler version
On 10 Aug 2002, Eric Rescorla wrote:
It's generally a bad idea to sign RSA data directly. The RSA
primitive is actually quite fragile. At the very least you should
PKCS-1 pad the data.
-Ekr
This is true. Cyclopedia Cryptologia has a short article detailing
some of the attacks against direct
From: Eugen Leitl [mailto:[EMAIL PROTECTED]]
1) What's the name of the technique of salting/padding an
small integer
I'm signing with random data?
If you have something in mind one does as in PKCS#1 v1.5 _encryption_
padding for RSA, i.e. fixing the top bytes and adding random bytes
Seth David Schoen [EMAIL PROTECTED] wrote:
R. Hirschfeld writes:
From: Peter N. Biddle [EMAIL PROTECTED]
Date: Mon, 5 Aug 2002 16:35:46 -0700
You can know this to be true because the
TOR will be made available for review and thus you can read the
source and decide for yourself if it
there are two possible answers:
1) it just has to be at least as secure at the risks (doing something might
improve the situation so that some number of vulnerabilities ... but not
all ... are minimized).
2) one of the excuses for not spending the money on secure software ... as
opposed to the
At 10:56 AM 8/12/02 +0100, Paul Crowley wrote:
...
Here's the game. Our attacker selects an algorithm MUNGE which takes
an unbounded stream of random bits as input and generates random
strings as output. We then select a key K and reveal it to the
attacker. We take a secret unbounded stream,
Adam Back writes:
+---++
| trusted-agent | user mode |
|space | app space |
|(code ++
| compartment) | supervisor |
| | mode / OS |
+---++
| ring -1 / TOR |
David Wagner wrote:
To respond to your remark about bias: No, bringing up Document Revocation
Lists has nothing to do with bias. It is only right to seek to understand
the risks in advance. I don't understand why you seem to insinuate
that bringing up the topic of Document Revocation Lists
At 07:30 PM 8/12/2002 +0100, Adam Back wrote:
(Tim Dierks: read the earlier posts about ring -1 to find the answer
to your question about feasibility in the case of Palladium; in the
case of TCPA your conclusions are right I think).
The addition of an additional security ring with a secured,
I think you are making incorrect presumptions about how you would use
Palladium hardware to implement a secure DRM system. If used as you
suggest it would indeed suffer the vulnerabilities you describe.
The difference between an insecure DRM application such as you
describe and a secure DRM
At 09:07 PM 8/12/2002 +0100, Adam Back wrote:
At some level there has to be a trade-off between what you put in
trusted agent space and what becomes application code. If you put the
whole application in trusted agent space, while then all it's
application logic is fully protected, the danger
At this point we largely agree, security is improved, but the limit
remains assuring security of over-complex software. To sum up:
The limit of what is securely buildable now becomes what is securely
auditable. Before, without the Palladium the limit was the security
of the OS, so this makes a
12 matches
Mail list logo
