Re: hiding a counter


Rainer Weikusat wrote:

David Schwartz <davids@xxxxxxxxxxxxx> writes:

Or, to put it another way, it is provable that every public-key
encryption scheme has this 'flaw'.

This is not 'a flaw of public key encryption system' but a technical
property of 'encryption', namely, the encryption key can be used the
encrypt data. After all, that's its purpose.

No, this is a flaw of public key encryption systems.

It is pointless to call this 'a flaw'. 'Public key encryption' means
the encryption key is public (hence the name) and that means,
everybody can use it to encrypt something. That's the point of it
being 'public'.

However, the public key can, provably, also be used for decryption.

Private key systems do not have to have this flaw.

The proper opposites would be 'asymmetric encryption' (with different
keys used for encryption and decryption) and 'symmetric encryption'
(only one key used for both). Since the encryption key for a symmetric
cryptosystem can be used to decrypt encrypted messages, it must be
kept secret. Which leads to the chicken-and-egg-problem asymmetric
cryptosystems try to address, namely, that, in order to communicate
with someone using symmetric encryption, the secret key must be
communicated over a secure channel first. But if there is already a
secure channel, why not use that for communicating directly?

Because the secret channel is only intermittently available.

In fact, it appears to be a fatal flaw until you realize that it's
possible to design systems where the flaw is impossible to exploit
*in* *practice*.

Right. 'Encryption' looks 'fatally flawed' until you realize the brute
force searching through the space of possible messages is not
technically feasible, given a sufficiently strong algorithm.

It's not just not technically feasible, it can be made literally
impossible. A one-time pad is the most obvious example of this.

A 'one-time pad' is the only example of this. All other cryptosystems
can be broken by doing a brute force search of the whole keyspace.

No, that is not true. Maybe you're not reading what I wrote, but I
already addressed this point.

Suppose I take a random 16-byte message and encrypt it with a random
128-bit AES key. With the encrypted output and all the computing power
in the world, you could not determine the message.

With public key cryptosystems, however, it cannot be made literally
impossible. I can only be made not technically feasible.

See above.

You are really not listening to what I am saying.

But with DRM, the _decryption key_ must be included, not the
_encryption key_. Meaning, all an attacker needs to do is to locate
this key (and the code using the key is avaible to him) and use it to
decrypt the data without brute-forcing anything.

You can prove that anything you can do with one key you can do with
the other. It just isn't practical. Consider any operation you can
perform with the private key. you can perform the same operation with
the public key, simply try all inputs until you get the right
output.

Since the message space is literally inifinitvely large, that's beyond
'not practical', its ludicrous. A brute force attack would still
rather be targeted at searching the keyspace.

Right, that's my point. Simply proving that an attack is possible in
principle is insufficient. It is still possible that the attack can be
"ludicrous" from a practical perspective.

The point is, in practice, there is no difference between something
that is impractical and something that is impossible. At least, not
until it becomes practical.

So proving that it is possible to break any DRM system is not useful.
It is possible to break any PK system too.

You are confusing yourself with your weird comparisons. Brute-force
attacks agains asymmetric cryptosystems are easier than brute-force
attacks against symmetric cryptosystem, provide one of the keys of the
asymmetric cryptosystem is avaible (say, because it is a 'public'
encryption key). But this is completely besides the point because
there is no reason to 'break' the encryption of a DRM system, neither
by bruteforce or cryptoanalisys because the key used to decrypt the
data must be available to the same person that is not supposed to be
able to decrypt it, because the DRM'ed content must be decrypted to be
perused.

You are trying to take my analogy too far. My point is not that DRM is
as secure as public key cryptosystems. My point is that your
particular argument that DRM is not secure equally well applies to
public key cryptosystems.

But a DRM scheme does not need to be broken, see above. It's like
'securing' access to something by locking the door, putting the key
below the doormat and only telling 'authorized people', but the door
is in a public place and anybody may watch those to his hearts
content.

If we accepted your argument, we would have to reject all public key
encryption schemes.

Feel free to do so if you really don't understand the difference.

No, I will instead reject your argument. You must demonstrate that the
attacks are *practical*, not just possible.

DS

.

Relevant Pages

  • Re: Encrypted network communication
    ... Bob) communicate over an insecure channel. ... This type of encryption uses a single shared, ... Secret-key encryption algorithms use a single secret key to encrypt and ... unauthorized users and a public key that can be made public to anyone. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: RSA keys, encryption and PGP-like cryptosystems
    ... relationship between RSA keys and encryption keys in PGP-like cryptosystems? ... That's the way a lot of cryptosystems work. ... I first have to generate an RSA key for myself. ... commenting on the probablility of such an attack, ...
    (sci.crypt)
  • RE: PGP scripting...
    ... cryptosystems, ... In these systems divulging your private key compromises the public ... Here is a quick over view of the public key encryption routines (the ...
    (SecProg)
  • RE: Cannot decrypt files encrypted using Crypto API on a different
    ... previous message which uses the recipien't public key.) ... KEK (key encryption key) to protect the session key. ... embedded into your client app and server code). ... but what is the point to encrypt the data if ANYBODY can decrypt it (since ...
    (microsoft.public.platformsdk.security)
  • Re: Encrypted files -- would this work to get them back?
    ... I'm guessing it's there because you use the public key to encrypt your ... it is not very useful in cracking the encryption. ... I still might be able to recover it if it's still there. ... I was able to restore my old certificate and key but I'm stuck ...
    (microsoft.public.windowsxp.security_admin)