🚀 go-pugleaf

Since most passwords are taped under the users desk drawer, ultimately
encryption is pretty pointless.

However I must confess that when transmitting data, I am inclined to
opt for 'roll your own' as one can come up with such a whacky method
that not even the NSA could decrypt it.

Example :-
    Key :-  Gone With The Wind  
    Method :- 
         Word :-   PageNo, LineNo, WordNo, 1
         Letter :-  PageNo, LineNo, WordNo, 0
         Start Page  :-  Random
         Duplication :-  Minimized by forward use only
   Scramble :-
         Zip with password
   Post Scramble :- 
          Reverse and Interleave

Effectively this is a one time pad, and is pretty much unbreakable.

For simplicity one could use *the same EXE* as the 'many time pad'   

On Fri, 17 Nov 2000 03:58:28 +0100, "Bj�rge S�ther"
<REMOVE_bsaether@THIS_online.no> wrote:

>"Sundial Services" <info@sundialservices.com> skrev i melding
>news:3A149202.77DA@sundialservices.com...
>> You need to encrypt the data.  This means scrambling the data in such
>a
>> way that it can only be recovered if you know the 'one and only one'
>key
>> that will decrypt it.  Without that key, the information is worthless.
>
>This is one of the most paradox-al facts about computers and security:
>- Whenever I get back to a customer a few years later, the very same old
>password is still valid. They may have installed firewalls or whatever,
>but don't care about whether I get drunk and tell anyone the admin
>password so that a crook has got all he needs...
>
>128 bit encryption, my a....;-)
>
>Part from that (which isn't your fault, anyway), a well written,
>informative tech-tip !
>
>A (little) tech tip on the very same topic: Whenever a key is to be
>checked, add (if possible) a noticeable delay, or use an algoritm that
>involves a *lot* of processing. if checking 1 key value takes 1 second,
>a hacker will only be able to test for 3600 keys / hour....
>I once created a password cracker for Paradox. Checking one password at
>a time was hopelessly slow. I seem to remember being able to check 200
>passwords in one pass, this speeded up a *lot*. Anyway, it was too slow
>to crack more than 5-char pwds...;-)
>--
>Bjoerge Saether
>Consultant / Developer
>Asker, Norway
>bsaether.removethis@online.no (remove the obvious)
>
>
>

J French wrote:
> 
> Since most passwords are taped under the users desk drawer, ultimately
> encryption is pretty pointless.
> 
> However I must confess that when transmitting data, I am inclined to
> opt for 'roll your own' as one can come up with such a whacky method
> that not even the NSA could decrypt it.
> 


Even though I agree with "Sundial Services" in his suggestion
that you use a commercial encryption package instead of 
"rolling your own",  I think everyone should do a "roll your
own" a few times before they use a package purchased elsewhere.

I think the insights into encryption that you gain by doing 
so are invaluable.   Those insights will help you to understand
the benefits and limitations of whatever commercial package you
do eventually buy - and they should help a little when it 
comes time to integrate someone elses encryption software into
your own program.


Rob

"Sundial Services" <info@sundialservices.com> skrev i melding
news:3A149202.77DA@sundialservices.com...
> You need to encrypt the data.  This means scrambling the data in such
a
> way that it can only be recovered if you know the 'one and only one'
key
> that will decrypt it.  Without that key, the information is worthless.

This is one of the most paradox-al facts about computers and security:
- Whenever I get back to a customer a few years later, the very same old
password is still valid. They may have installed firewalls or whatever,
but don't care about whether I get drunk and tell anyone the admin
password so that a crook has got all he needs...

128 bit encryption, my a....;-)

Part from that (which isn't your fault, anyway), a well written,
informative tech-tip !

A (little) tech tip on the very same topic: Whenever a key is to be
checked, add (if possible) a noticeable delay, or use an algoritm that
involves a *lot* of processing. if checking 1 key value takes 1 second,
a hacker will only be able to test for 3600 keys / hour....
I once created a password cracker for Paradox. Checking one password at
a time was hopelessly slow. I seem to remember being able to check 200
passwords in one pass, this speeded up a *lot*. Anyway, it was too slow
to crack more than 5-char pwds...;-)
--
Bjoerge Saether
Consultant / Developer
Asker, Norway
bsaether.removethis@online.no (remove the obvious)

J French <jerry@iss.u-net.com> schreef in berichtnieuws
3a1511c3.3547255@news.u-net.com...

> Effectively this is a one time pad, and is pretty much unbreakable.
>

Sure, but not just "pretty much" , a one time pad *is* unbreakable IF :
- the key is random.
- the key is at least as long as the plaintext message.
Even today, numerous radio messages from WWII cannot be decoded, because
they were encrypted with one time pads.

--
Regards,

Dirk Claessens
---------------------------------------------------------
http://www.claessens16.yucom.be
Attention: All spamshields raised; E-mails will bounce!
---------------------------------------------------------

On Sat, 18 Nov 2000 11:25:09 +0100, "Dirk Claessens"
<will.bounce@back.com> wrote:

>J French <jerry@iss.u-net.com> schreef in berichtnieuws
>3a1511c3.3547255@news.u-net.com...
>
>> Effectively this is a one time pad, and is pretty much unbreakable.
>>
>
>Sure, but not just "pretty much" , a one time pad *is* unbreakable IF :
>- the key is random.
>- the key is at least as long as the plaintext message.
>Even today, numerous radio messages from WWII cannot be decoded, because
>they were encrypted with one time pads.

Totally agreed - what I was suggesting(/hinting at) was re-using a one
time pad a few times - a subtle difference, but much more convenient
for applications.

>
>--
>Regards,
>
>Dirk Claessens
>---------------------------------------------------------
>http://www.claessens16.yucom.be
>Attention: All spamshields raised; E-mails will bounce!
>---------------------------------------------------------
>
>
>

On Fri, 17 Nov 2000 03:58:28 +0100, "Bj�rge S�ther"
<REMOVE_bsaether@THIS_online.no> wrote:

>
>This is one of the most paradox-al facts about computers and security:
>- Whenever I get back to a customer a few years later, the very same old
>password is still valid. They may have installed firewalls or whatever,
>but don't care about whether I get drunk and tell anyone the admin
>password so that a crook has got all he needs...
>
Set a time limit for password validity, so the user is forced to
change it. And when doing so, prevent him from changing to the same
password again. Even better, keep a list of, say, the last 10
passwords used and prevent any of these to become the current
password. Also, require a minimum password length.
Not foolproof, but may help a lot...
>128 bit encryption, my a....;-)
>
>Part from that (which isn't your fault, anyway), a well written,
>informative tech-tip !
>
>A (little) tech tip on the very same topic: Whenever a key is to be
>checked, add (if possible) a noticeable delay, or use an algoritm that
>involves a *lot* of processing. if checking 1 key value takes 1 second,
>a hacker will only be able to test for 3600 keys / hour....
>I once created a password cracker for Paradox. Checking one password at
>a time was hopelessly slow. I seem to remember being able to check 200
>passwords in one pass, this speeded up a *lot*. Anyway, it was too slow
>to crack more than 5-char pwds...;-)
>--
Lock the account after, say, 10 invalid passwords. Unlocking procedure
should include investigation of why 10 invalid passwords were entered.
Of course, this requires some kind of security department or
oficial...
>Bjoerge Saether
>Consultant / Developer
>Asker, Norway
>bsaether.removethis@online.no (remove the obvious)
>
>
>
Pierre Gemis

On Sat, 18 Nov 2000 19:34:26 GMT, softal@redestb.es (Pierre Gemis)
wrote:

>On Fri, 17 Nov 2000 03:58:28 +0100, "Bj�rge S�ther"
><REMOVE_bsaether@THIS_online.no> wrote:
>
>Set a time limit for password validity, so the user is forced to
>change it. And when doing so, prevent him from changing to the same
>password again. Even better, keep a list of, say, the last 10
>passwords used and prevent any of these to become the current
>password. Also, require a minimum password length.
>Not foolproof, but may help a lot...

Hmm, I had to do this once, it created havoc as the users 'forgot'
their new passwords, 

Although it gives me an idea - for Online applications the idea of a
second (hidden) password from a list is rather interesting.