🚀 go-pugleaf

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
> stream, so it's repeatable).  It also rotates bits and uses a modified XOR
> based on the offset in the password and a value in the random number stream.
> It doesn't store the password in the header of the file, but it does store a
> folded and mangled version which can't possibly be decrypted, but can be used
> as a fingerprint test to see if the password entered was valid -- a bit nicer
> than decrypting a file and finding out that you got crap back.  :-)  Actually,
> the length of the password isn't stored, so if it were to try decoding, it
> would probably start off at the wrong position anyway.  And when the passcode
> can be anywhere from 2 to 253 characters, fat chance on breaking it by brute
> force or guessing.  I have no idea how it would stand up to real cryptography
> cracking, though.
> 

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.

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.

> > 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 :-)

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 :-)

[...]

Christopher Eltschka
If you are missing information, just remember, that this article was
moving
through the net with high relativistic speed, so any shortening comes
from lorentz
contraction...