🚀 go-pugleaf

Frank Heckenbach wrote:
> 
> 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... :-)

Maybe you'd like to try breaking mine, using a detailed description of the algorithm?  
:-)  Well, I'm sure it's probably breakable, but I'd like to think I've thrown enough 
data obfuscation in to make it reasonably secure.  I wasn't looking to make it 
bullet-proof, just solid enough to keep crypto-clueless people at bay. . . .

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

Oh, I *know* I won't.  And I'm not really trying to.

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

Like the position of the write protect tab?  :-)

> 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

Sending the disk is technically easy, though a bit cumbersome on bandwidth.  There are 
plenty of utilities to make disk images to files and reverse the process.  But that was 
more of a whimsical/impractical idea on my part anyway, not something I'm ever likely to 
bother trying.

> "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.

True.

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

No, the real key is a user-specified password (like what you use to login in to your net 
account), and I think I figured the brute force number for passwords up to 64 characters 
was about 6.3e153.  The random stream is just used for recoding the data.

> (*) 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.)

The seed isn't forced with enough frequency to fall within the same 18.2s period.

> 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!

No argument there.  :-)

> [...]
> 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...)

These days, those registers aren't much more than urban legend.  Those only applied to 
earlier video implementations that could fry the monitor if the signal generated by the 
card was outside the frequency range that that the monitor could handle.  Of course, 
doing this would mean you have to put that disclaimer that says "not responsible for any 
damages" in REALLY big letters.  :-)

> [...]
> 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!)... ;-)

Ugh.  Methinks you forgot "sacrifice small furry animal by running through the automatic 
document feeder on the color scanner, and post results to alt.binaries.tasteless".  
<bzzzt> <splat> <crunch>  Ewww.

> Never knew cryptography was such a funny topic.

Hee hee.  Well, this is getting a bit long.  I suppose further discussion of this 
silliness is now best taken to e-mail. . . .

> Frank

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