🚀 go-pugleaf

Christopher Eltschka wrote:
> 
> Scott Earnest wrote:
> > KnightBird wrote:
> > >
> 
> [...]
> 
> > I wrote an encryption/decryption engine myself (based on a friend's ideas).  I
> > set it up to use random numbers, with a shifting seed (based on the random
> > [...]
> 
> I guess the encryption would be safer, if you used a wo-step mechanism:
> First create a random key, which you encrypt with your passcode.
> Then encrypt the file with the random key.
> The advantage of this is, that the part where you're passcode is used,
> has no structure, so the structure of your passcode is hidden. And, the
> code which with your file is encrypted does have no structure either,
> so it can't look out of the encrypted data.
> It even allows you to change your password quickly if someone gets to
> know your password, but didn't have access to the file then:
> Only the encryption of the key would have to be re-encrypted, the rest
> of the file remains unchanged.

Hmmm, I may have to try something like that. . . .  The only thing that I have a 
real problem with is if someone's been working to crack the encryption without the 
password, would re-encrypting only the key really slow the process down much?

One thing that crossed my mind was creating a 1.44MB key disk and using that as a 
turn-key.  In theory, you could use any 1.44 as a key (through low-level reading). 
Just a consideration.  "Uh oh, somebody changed the date on GLORP.EXE, now I can't 
decrypt my project text!"  Hmm.

> Another good option is to compress before encrypting. This way you get
> not only smaller files, but also less easy to decrypt ones, as compressing
> removes redundant information which could be used to break the code.

True, something that hadn't crossed my mind.  Though, being a randomized stream, 
the possibility of seeing the password by writing a file with the same character 
repeated many times (like a 0) is just about nil.  And using a random procedure 
with a period of 2^32, it would be a long time before a duplicate stream would come 
around again.

> > > The encryption was accomplished by asking for a string.  I was in a hurry,
> > > so I just used Readln..  <owch>  Then, I started, byte for byte, reading
> >
> > Well, I'd suppose that if you clean up memory and make sure the keyboard buffer
> > is flushed before you start reading the password might make it a bit more
> > secure to cracking.  OTOH, I'm not sure anyone would want to use a program that
> > puts the password up on the screen so rubberneckers could get a better look at
> > it. . . .
> >
> 
> Well, you could put the following instructions into the manual:
> 
> "Hint: To get better security, you should turn off your screen before
> typing your password. This way, no one will be able to read it."
> You could even tell it a way of power saving :-)
> 
> Ah, yes, and don't forget to clear the screen after reading the password
> -
> else there comes the big surprise, when the user switches the screen on
> again :-)

Heh.  Better to read a character at a time without display and append it to the 
string (using readkey() in TP, but implementations vary).

> BTW, if you want to have maximum safety, you'd have to get your password
> directly from the keyboard controller, so the characters are never written
> to any general-known memory location (like the keyboard buffer) or passed
> to BIOS routines that could be hooked. As bonus you get the possibility to
> make passwords like "Press left Shift, then, while keeping it pressed,
> press right Alt, then relase left Shift, Press and release A, and then
> release right Alt, then press F1, press left Ctrl, Release F1, press
> left Shift, Release left Ctrl ..." This "Password" might not be cracked too easy
> :-)

Hmm, a password based on scancodes.  And to think I liked my password entry because 
it allows for extended key entries.  I could see the new craze in security (heavily 
advocated by makers of crummy keyboards, of course):

Computer:  "Please enter password for encryption."

<user smacks head on keyboard, depressing multiple keys>

Computer:  "Please re-enter for confirmation."

<user smacks head on keyboard once more>

Computer:  "Thank you, password accepted.  Encrypting...."

Ha ha!  And you think you'll have the answer by figuring out what I typed!  Won't 
you be surprised that you need to figure out how to smack your head in precisely 
the same way I did to encrypt the file.  ;-)

> [...]
> 
> Christopher Eltschka

-- 
Scott Earnest                      | _,-""-_,-""-_,-""-_,-""-_,-""-_,-" |
setech@ix.netcom.com (primary)     | We now return you to our regularly |
sinykal@cyberspace.org (alternate) | scheduled chaos and mayhem. . . .  |