Subject: Hidden session key generation & storage

From: Erron Criddle <[email-masked]>
Date: Mon, 12 Jun 2000 10:47:37 +0800

To all,

This is only slightly related to PGP, however:

I was wondering if there is some "standard" out there that defines how a 
session key is stored/saved/hidden after a file is encrypted and stored on 
a computer system using the same key. Ideally, the only thing that *should* 
be able to decrypt the file is the same computer program that generated the 
key.

You can play around with binary files, the XOR function, CRC checks, 
Hashing algorithms and a host of other "tricks" to "make life very 
difficult" for the reverse engineer, however is there a 100% secure way for 
an executable to encrypt and store data (to be decrypted later on by the 
same program)?

TIA.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

---

From: Paul Koning <[email-masked]>
Date: Mon, 12 Jun 2000 10:38:10 -0400 (EDT)

>>>>> "Erron" == Erron Criddle <[email-masked]> writes:

 Erron> To all, This is only slightly related to PGP, however:

 Erron> I was wondering if there is some "standard" out there that
 Erron> defines how a session key is stored/saved/hidden after a file
 Erron> is encrypted and stored on a computer system using the same
 Erron> key. Ideally, the only thing that *should* be able to decrypt
 Erron> the file is the same computer program that generated the key.

No.

Done correctly, the only way to decrypt the file is for the human who
owns the key to supply that key.

That is the PGP way...

 Erron> You can play around with binary files, the XOR function, CRC
 Erron> checks, Hashing algorithms and a host of other "tricks" to
 Erron> "make life very difficult" for the reverse engineer, however
 Erron> is there a 100% secure way for an executable to encrypt and
 Erron> store data (to be decrypted later on by the same program)?

No, there is not.  That's why programs that offer real security DO NOT
DO THIS.

If you see a program that does do this -- i.e., can decrypt your
encrypted file without asking you for the key -- then it is by
definition insecure and should be thrown in the garbage can.

     paul