Thanks for going back to the rot.
It is always good to look at the objective.
problem statement:
data kept locally (like logs, order data)
must be protected against the local system users
(programs, real usrs, real hackers)
first proposal: use symmetric encryption
problem: encrypting key is present somehow
on the system, so in theory local users
may be able to get at the data.
(risk assessment: how hard, how likely ?)
improvement: use assymmetric encryption
only one of the two keys is known/accessible locally
assumption: local encryption possible, local
decryption requires breaking the assymetric encryption
[FWIIW: I like this idea]
Question: two stage or single stage?
two stage: symmetric encryption with a key encrypted
assymetric
one stage: assymetric only
Question: is one stage assymetric OK?
I think this is the point were we are at, correct?
My answer: be careful, it may not be OK.
Attack: repeat the encryption for possible plain texts.
If that space is smaller than the key space, you
have a better attack.
example - unclear: db with credit card numbers
Find 'a' credit card number: requires enumeration over number
of creditcards. Which search space is larger?
example - clear: did you buy at company xxx?
Search space is the amount of entries: small.
example (logs) : did the IDS pick up my attack?
I known fairly accurately what the data would be,
so I just look in the database (or traffic) to find
this evidence.
I hope this makes it clear.
With assymtric encryption you have one attack you
do not have with symmetric. You have access to one of the
keys (the public). So you can enumerate plaintexts
and produce encrypted texts to match the target encrypted text.
[note, the dual case is obvious: if it were
encrypted with the private, you just use the public]
In the two stage approach, the thing you encrypt
is a total random key making this attack worthless.
Jason Coombs wrote:
> Andre Mariën wrote:
>
>>We are talking about confidentiality I thought.
>
>
> I thought we were talking about the value of asymmetric encryption in a
> scenario where a sending box (the encryptor) needs to effectively get rid of
> the data ASAP but do so in a way that is recoverable on another box (the
> decryptor) which is purposefully not accessible from the encryptor via the
> network.
>
> Asymmetric encryption is also valuable for bulk encryption in a scenario
> where a software vendor or other already-public entity needs to communicate
> authentic data ("here is the latest build of our software") but doesn't want
> to deal with the problems of PKI (certificates, certificate chains, digital
> signatures, etc.) and wants some digital communications authentication but
> doesn't want to try to publish a list of authentic hashes (which, absent a
> digital signature and PKI, a third-party can simply tamper with upstream
> from an end-user) or distribute executable bytes that most people will
> simply execute without further verification anyway -- by encrypting the
> software build with the vendor's private key, any third party who wishes to
> execute the software must first obtain the vendor's public key and decrypt
> the software. Either the software decrypts with the vendor's public key
> (giving a sort of lightweight digital signature) or it doesn't and if it
> doesn't then there is no way to execute the bytes and the whole computer
> world is a lot safer as a result.
>
> This thread was started on 1/7/2003 when Andrew MacKenzie wrote:
>
>
>>We (my client) have a system that loads orders into an Oracle DB, and
>>processes billing (Java/Solaris based). One of the 'decrees' from my
>>client is that all files that store 'sensitive' data (customer info and
>
> the
>
>>like) shall be PGP encrypted, and *never* be stored on a HDD in
>>un-encrypted form (even while processing said file).
>
>
>>I can understand the desire to archive these files in encrypted forms, and
>>to encrypt these files while transporting out of the system. But I think
>>this idea goes a bit too far as to be more counter-productive than useful.
>>After many days of fighting with 'pgp -f' and modifying processes to use
>>stdin/stdout, I've gotten much of this working.
>
>
>>My question therefore is: is all this worth the trouble?
>
>
> -----Original Message-----
> From: Andre Mariën [mailto:andre.marienat_private]
> Sent: Thursday, January 23, 2003 9:05 PM
> To: jasoncat_private
> Cc: Glynn Clements; Beatie, Breck (ISSMountain View);
> secprogat_private
> Subject: Re: PGP scripting...
>
>
> It may be just me, but I am getting confused.
> If we keep both private and public key secret,
> why not use plain old symmetric cryptography?
> We are talking about confidentiality I thought.
> If we take it to non-repudiation there still are some merrits.
>
> One of the things about public/private keys is,
> well, the public key can be public.
>
> -- André
>
>
> Jason Coombs wrote:
>
>>Interesting discussion -- just a point of clarity:
>>
>>Glynn Clements wrote:
>>
>>
>>>To take an extreme (and somewhat contrived) example, suppose that you
>>>know that the message will either be "The deal is on" or "The deal is
>>>off"; although the message would occupy at least 112 bits as ASCII,
>>>you only really have one bit of data, and you would only have to
>>>encrypt the two candidate messages to determine which one was actually
>>>sent.
>>
>>
>>Previously Andre Marien stated:
>>
>>
>>>If there are n possible messgaes, it only takes at most n trials to
>>>decrypt the message, no matter your key size(if the encrypting key is
>>>known; typically it is the public key and it is known)
>>
>>
>>If the public key used to perform the encryption is known, then it only
>>takes at most n trials to decrypt a message encrypted with that public
>
> key.
>
>>Without the public key, you're still stuck brute-forcing the key length
>>because the RSA algorithm does not result in predictable placement of
>>ciphertext bits that correspond to the plaintext "n" or "f" -- you can't
>>just ignore the rest of the cryptographic transformation and concentrate
>
> on
>
>>scanning a single byte until it comes up "n" or "f" and then attempt to
>>transform the entire ciphertext message with the potential key until you
>>find the right one.
>>
>>You can mount a chosen plaintext attack with "The deal is on" and one in
>>parallel with "The deal is off", but since you don't know the key your
>>attack is going to take a very long time and span a good deal of the
>>available key space.
>>
>>Asymmetric bulk encryption can also be used with a random initialization
>>vector the same way that IVs are used in symmetric bulk encryption with
>>feedback modes like Cipher Block Chaining. You then have a secret session
>>key (the IV) that makes brute-force chosen plaintext attacks unreasonable,
>>while preserving the feature of practical unrecoverability of the
>
> plaintext
>
>>in the event that the secret session key is captured along with the
>>ciphertext. It is arguably more difficult for an adversary to capture [the
>>private key from an asymmetric key pair AND the IV AND the ciphertext]
>
> than
>
>>it is to capture [the symmetric secret key AND the IV and the
>
> ciphertext] --
>
>>for the simple reason that at the point of encryption the softwre that
>>implements the asymmetric bulk cipher is never in possession of the
>
> private
>
>>key necessary for decryption.
>>
>>Jason Coombs
>>jasoncat_private
>>
>>-----Original Message-----
>>From: Glynn Clements [mailto:glynn.clementsat_private]
>>Sent: Wednesday, January 22, 2003 10:06 AM
>>To: Beatie, Breck (ISSMountain View)
>>Cc: secprogat_private; Andre Marien
>>Subject: RE: PGP scripting...
>>
>>
>>
>>Beatie, Breck (ISSMountain View) wrote:
>>
>>
>>
>>>>Please do not use public key encryption for bulk data, even if
>>>>you accept the long times. It is a bad idea. If there are n
>>>>possible messgaes, it only takes at most n trials to decrypt
>>>>the message, no matter your key size (if the encrypting key is known;
>>>>typically it is the public key and it is known).
>>>>This problem is justification in itself to have a two stage system
>>>>for encryption of bulk data.
>>>>(there is someone at counterpane that can explain it in more detail ;-)
>>>
>>>I'm not sure I understand the point of this message. It seems that
>>>you are saying that you can figure out the cleartext message by taking
>>>the n possible cleartext messages and encrypting with the known public
>>>key until you find the cipher text. That much makes sense, but since
>>>we were talking about encryption of bulk data it seems that the number
>>>of possible messages would be VERY large and such an approach would
>>>not be workable.
>>>
>>>It seems that your comment would even argue AGAINST the "two stage"
>>>system that you're talking about. The total number of possible symmetric
>>>keys would be much less than the total number of possible messages.
>>>
>>>But then I'm a bit of a crypto ignoramus. If you (or someone) would
>>>elaborate a bit I would be grateful.
>>
>>
>>I think that you're misinterpreting the term "bulk data" slightly;
>>it is referring to the actual plaintext (subject to any
>>transformations such as compression), not necessarily to a *large*
>>amount of data.
>>
>>The context may greatly reduce the set of possible plaintexts, even
>>below the size of a symmetric key. Suppose that you can guess almost
>>the entire plaintext (e.g. because it's generated automatically by a
>>specific piece of software), and the only thing which you *can't*
>>guess is a very small section e.g. a credit card number, you could
>>attempt a brute-force search of all plausible credit card numbers,
>>which is likely to be easier than brute-forcing a 128-bit symmetric
>>key.
>>
>>To take an extreme (and somewhat contrived) example, suppose that you
>>know that the message will either be "The deal is on" or "The deal is
>>off"; although the message would occupy at least 112 bits as ASCII,
>>you only really have one bit of data, and you would only have to
>>encrypt the two candidate messages to determine which one was actually
>>sent.
>>
>>In short, with the two-stage approach, you have a fixed lower bound on
>>the number of possible plaintexts, and for a 128-bit key, this is well
>>beyond brute-force viability with current hardware, even for the NSA.
>>OTOH, directly encrypting the plaintext provides no such lower bound.
>>
>>--
>>Glynn Clements <glynn.clementsat_private>
>>
>
>
> --
> André Mariën
>
> Ubizen http://www.ubizen.com
> Phone +32 16 28 70 00
> Fax +32 16 28 71 00
>
--
André Mariën
Ubizen http://www.ubizen.com
Phone +32 16 28 70 00
Fax +32 16 28 71 00
This archive was generated by hypermail 2b30 : Fri Jan 24 2003 - 11:10:52 PST