🚀 go-pugleaf

Scott Earnest <setech@ix.netcom.com> writes:
> 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?
Probably not! I'm no expert in cryptography, but if you want REAL security,
read some good books or get some other information first. Any attemps to do
encryption quickly will probably be relatively easy to break. (That's the only
thing I can say from experience. I did some encrytion for my own use that I
thought was quite secure. But when I lost the key to some data I needed, I
found out it wasn't quite as hard to break the code... :-)

And after all, why reinvent the wheel? There is at least one pretty good
enryption program available (PGP), and without demoralizing, I guess you won't
be able to do something better.

> 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.
Might I suggest using a write-protected disk? ;-)
(There are things that get changed even easier than the file's dates...)

Apart from this, this seems a good thing to do - if you can, i.e. no
transmission over the net around the world (how to send the disk?), and no
"spies" that would get a quick copy of your disk, and of course not using your
precious disk on any unknown system (they could log each track read without
you noticing). With a key length of 1.44 MB you have *perfect* security for
1.44 MB of data - no more, no less.

> 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.
I'm not completely sure what you mean here, but if you intend to generate a
long key with a sequence generated by BP's random function, this is probably
not a good idea. The whole stream would be determined by the value of RandSeed
at the beginning. So there are only (sic!) 2^32 (*) possibilities to try by
brute force cracking - far too few against a serious cracker (with an
appropriate amount of computing power). Interesting numbers of possibilities
for crytography are in the range of 10^XX or 10^XXX.

(*) Probably even less possiblities, because RandSeed is initialized based on
the current date and time, which increments only 18.2 times a second. So if
you only know the week the code was generated, you only have to try 11 million
possibilities! (Sure, you could fake the date, but it wouldn't really change
much.)

Not without a reason, PGP for example lets the user type many keys and
calculates a random sequence from the precise delays between the key strokes.
A pure software random generator will not suffice for this purpose!

> > 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).
Aren't there VGA register writes that can destroy the monitor? This way you'd
be REALLY sure that no-one will read the password typed! ;-)
(Any much more creative than just setting TextAttr to 0...)

> > 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.  ;-)

How primitive! I'd like something like the following (of course you can bang
any part of your body against any part of your computer in between):

Open CD-ROM drive, toggle the TURBO switch, put a small piece of paper into
the left side of your floppy drive (covering the write-protect hole, but not
the disk-present one), turn off printer, press RESET button (this one might
get difficult...), and move your mouse to the right for 5 meters without
stopping (this gives GREAT security, since few people have that long mouse
cables (except wireless mice) - or tables!)... ;-)

Never knew cryptography was such a funny topic.

Frank