Cryptography-Digest Digest #174, Volume #14 Wed, 18 Apr 01 13:13:01 EDT
Contents:
Re: XOR_TextBox: Doesn't write to swap file if... (HiEv)
Challenge/Response - DSL (David Opolon)
A practical idea to reinforce passwords (=?iso-8859-1?q?Harald=20Korneliussen?=)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: NSA is funding stegano detection (Niels Provos)
Re: Proof of RSA ("Michael Scott")
Re: A practical idea to reinforce passwords (Mok-Kong Shen)
Re: NSA is funding stegano detection (Mok-Kong Shen)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: AES poll (David Wagner)
Re: C code for GF mults (David Eppstein)
Re: Reusing A One Time Pad ("Tom St Denis")
Re: A practical idea to reinforce passwords ("Tom St Denis")
Re: A practical idea to reinforce passwords ("Tom St Denis")
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: A practical idea to reinforce passwords ("Paul Pires")
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: A practical idea to reinforce passwords ("Jakob Jonsson")
Re: A practical idea to reinforce passwords (Volker Hetzer)
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: A practical idea to reinforce passwords (newbie)
Re: "UNCOBER" = Universal Code Breaker (John Savard)
----------------------------------------------------------------------------
From: HiEv <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR_TextBox: Doesn't write to swap file if...
Date: Wed, 18 Apr 2001 12:22:29 GMT
HiEv wrote:
>
[snip]
> Tell you what though, you send me two XORed files encrypted with the
> same OTP and I'll show you how to decrypt the shorter one entirely, the
> same number of bytes of the longer one, and recover that much of the OTP
> to boot! :-)
Whoops, scratch that bit, I mis-read something.
------------------------------
From: David Opolon <[EMAIL PROTECTED]>
Subject: Challenge/Response - DSL
Date: Wed, 18 Apr 2001 15:10:38 +0200
Do you guys know of challenge /response algorithms that yield to a ten
digit number ?
I'm wondering which algorithm is behing the alcatel DSL's modem
challenge/response system ?
a working example of the system is here (but I don't have the source of
the CGI) :
http://security.sdsc.edu/self-help/alcatel/challenge.cgi
thanks for your help,
David
P.S. : can you please reply also by mail
------------------------------
From: [EMAIL PROTECTED] (=?iso-8859-1?q?Harald=20Korneliussen?=)
Subject: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 14:57:38 +0000 (UTC)
I've come up with a way to reinforce passphrases
against brute-force attacks without memorizing longer
ones. This may already be in use, but I don't think so
because it should be configurable and I haven't seen
anything like that... It's really mostly for PGP but
it is relevant to everywhere passwords are used, so I
post it here.
My idea is that upon selecting a password, X bits of
random data is added to the password. You are not
informed of what these bits are, nor does the computer
store them. The computer only stores how many bits
there are, and brute-forces them every time you enter
you password.
The reason this is a good idea is: It only adds a few
bits of security, but it does this at something
important, something that is the weak link in schemes
like PGP. Logging in, or signing or what it is you do
will take slighty longer time, but this will not be
noticed - you only add so many bits your machine can
handle efficiently. The slowdown you experience will
be nothing compared the slowdown an attacker will
experience. He presumably has much larger computing
capabilities than you, but now _your_ capabilities
come into play too.
If there is something wrong with this approach, or if
it is for some reason impractical, please tell me!
Harald Korneliussen
______________________________________________________
Do You Yahoo!?
Organiser sammenkomsten på http://no.invites.yahoo.com
--
Posted from web3001.mail.yahoo.com [204.71.202.164]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 10:00:26 -0500
> Perhaps not - how old is your kid sister? ;-)
No ;-)
If I hear another reference to sister, mother, probe, or anything else
Freudian, I'm going to personally resurrect the stupid mother fucker so that
I can slowly torture him to death again. If that coke snorting son of a
bitch wasn't the devil himself he must have been a very close friend.
Ahh. Out with the bad thoughts, in with the good thoughts. No coffee in
the morning make Homer go crazy.
------------------------------
From: [EMAIL PROTECTED] (Niels Provos)
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: 18 Apr 2001 15:02:23 GMT
On 14 Apr 2001 21:00:41 GMT, Niels Provos wrote:
>I am also going to release a utility soon that wlll detect
>various steganographic schemes for images.
I just released stegdetect, an automated tool for detecting
steganographic content in images. You can find it at
http://www.outguess.org/detection.html
--
Niels Provos <[EMAIL PROTECTED]> finger [EMAIL PROTECTED] for pgp info
"Gravity is the soul of weight." - Anonymous.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Proof of RSA
Date: Wed, 18 Apr 2001 10:06:16 -0500
"sianglin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Can someone prove that, in RSA, D(E(M)) = M where M=message,
> E=Encryption, D=Decryption?
>
In the particular case where the encrypting exponent e is 3, a simple
explanation is possible.
Encryption is cubing mod n. Decryption is cube-rooting mod n. Clearly one is
the reverse of the other. And cube roots are unique if n and 3 have a
particular relationship - the factors of n, p and q, should be such that p-1
and q-1 are not multiples of 3. In this case a "cube rooting" exponent d is
easily found - [2*(p-1)*(q-1)+1]/3. It is easy to check that 3.d=1 mod
(p-1)*(q-1)
So C=M^3 mod n (encryption)
M=C^d mod n (decryption - "cube rooting")
Mike Scott
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 17:07:09 +0200
Harald Korneliussen wrote:
>
> I've come up with a way to reinforce passphrases
> against brute-force attacks without memorizing longer
> ones. This may already be in use, but I don't think so
> because it should be configurable and I haven't seen
> anything like that... It's really mostly for PGP but
> it is relevant to everywhere passwords are used, so I
> post it here.
>
> My idea is that upon selecting a password, X bits of
> random data is added to the password. You are not
> informed of what these bits are, nor does the computer
> store them. The computer only stores how many bits
> there are, and brute-forces them every time you enter
> you password.
I know too little. But isn't it that UNIX employs a
scheme like that for passwords?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: Wed, 18 Apr 2001 17:14:39 +0200
Niels Provos wrote:
>
> On 14 Apr 2001 21:00:41 GMT, Niels Provos wrote:
> >I am also going to release a utility soon that wlll detect
> >various steganographic schemes for images.
> I just released stegdetect, an automated tool for detecting
> steganographic content in images. You can find it at
>
> http://www.outguess.org/detection.html
I believe many readers would appreciate a short (concise)
and concrete description of the strategies/methods you
employ in that software.
M. K. Shen
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 10:16:29 -0500
> Collecting some of your messages would normally be all that is required.
That "some" would at least be proportional to the size of my pad. And I'm
guessing the computational time/power to extract messages would be
exponentially higher.
I think a modestly large OTP used in conjunction with other key encryption
technologies is realistically unbreakable. Those that feel they have to spy
on people to save the world know it, and are scared shitless by it. Better
start being nice to your neighbors, it will be your only defense shortly.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: AES poll
Date: 18 Apr 2001 15:33:06 GMT
Jack Lindso wrote:
>From reading the government document concerning the choice of AES I had the
>feeling that Rijindael was selected without evident/sufficient proof for
>being the best choice.
For what it's worth, the "polls" of the research community showed
a significant leaning towards Rijndael even before it was selected
by NIST. I, for one, think they made a fine choice, and I'm very
pleased with the results of the standards process.
------------------------------
From: David Eppstein <[EMAIL PROTECTED]>
Subject: Re: C code for GF mults
Date: Wed, 18 Apr 2001 08:20:39 -0700
In article <6kbD6.29231$I5.122867@stones>,
"Brian Gladman" <[EMAIL PROTECTED]> wrote:
> Do you know how to express Conway's method in terms of other forms of field
> representation?
No. I guess the question is, which element of his representation is "x"?
Once one knows that, it should be possible to find the minimal polynomial
s.t. p(x)=0.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 15:52:43 GMT
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bkb68$n56$[EMAIL PROTECTED]...
> > Collecting some of your messages would normally be all that is required.
>
> That "some" would at least be proportional to the size of my pad. And I'm
> guessing the computational time/power to extract messages would be
> exponentially higher.
>
> I think a modestly large OTP used in conjunction with other key encryption
> technologies is realistically unbreakable. Those that feel they have to
spy
> on people to save the world know it, and are scared shitless by it.
Better
> start being nice to your neighbors, it will be your only defense shortly.
"Modestly large OTP" is a meaningless description. An OTP must by
definition be the same size as the message. And if it's a true OTP you need
not encrypt it any "further" to get a more secure system, it's already
provably secure.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 15:55:32 GMT
"Harald Korneliussen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've come up with a way to reinforce passphrases
> against brute-force attacks without memorizing longer
> ones. This may already be in use, but I don't think so
> because it should be configurable and I haven't seen
> anything like that... It's really mostly for PGP but
> it is relevant to everywhere passwords are used, so I
> post it here.
>
> My idea is that upon selecting a password, X bits of
> random data is added to the password. You are not
> informed of what these bits are, nor does the computer
> store them. The computer only stores how many bits
> there are, and brute-forces them every time you enter
> you password.
> The reason this is a good idea is: It only adds a few
> bits of security, but it does this at something
> important, something that is the weak link in schemes
> like PGP. Logging in, or signing or what it is you do
> will take slighty longer time, but this will not be
> noticed - you only add so many bits your machine can
> handle efficiently. The slowdown you experience will
> be nothing compared the slowdown an attacker will
> experience. He presumably has much larger computing
> capabilities than you, but now _your_ capabilities
> come into play too.
>
> If there is something wrong with this approach, or if
> it is for some reason impractical, please tell me!
So if I get your system right your password really is "password"+R where R
is a random bit string nobody stores. The problem is your method relies on
the total entropy in the two being larger enough. If I used a dorky
password like "12345" then you will need a large R to compliment it. Ah...
but a large R means a slower login.
A simpler method is to use a MagStrip thingy where you write a random bit
string to a card. If you lose your card you revoke the key stored on it...
simple as that. Best of all you can have a bigger key on the MagStrip and
not be forced to memorize (or even know) the key.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 15:55:58 GMT
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Harald Korneliussen wrote:
> >
> > I've come up with a way to reinforce passphrases
> > against brute-force attacks without memorizing longer
> > ones. This may already be in use, but I don't think so
> > because it should be configurable and I haven't seen
> > anything like that... It's really mostly for PGP but
> > it is relevant to everywhere passwords are used, so I
> > post it here.
> >
> > My idea is that upon selecting a password, X bits of
> > random data is added to the password. You are not
> > informed of what these bits are, nor does the computer
> > store them. The computer only stores how many bits
> > there are, and brute-forces them every time you enter
> > you password.
>
> I know too little. But isn't it that UNIX employs a
> scheme like that for passwords?
No unix stores a two char SALT which is stored along with your password
afaik.
Tom
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 12:04:07 -0300
What some forget is the context where a word occure.
Just sample :
What is important for me is to discover the amount of credit transfer.
I look for dollars or $ in my cipher text
cipher text = 10010001000100101010...
keystream totally random = 1010101010001010101010...
suppose that $ or dollars = 0100010010
I have to slide my bit-string dollars in all the ciphertext bit by bit
until I find if it match. If it matches, it does not matter for me what
the fraction of random string is.
I continue.
I look for the amount.
Near dollars, at left, I try variable amount of six, 7 digits etc...
So the the more important in plain-text is not to recover all plain-text
because any plain-text has his own and important secret within bit
string.
If I discover this secret I uncovered the plain-text.
You can build the plaintext little by little trying to guess the words
of the context.
It is not important disclose "the" "or" etc...
John Savard wrote:
>
> On Tue, 17 Apr 2001 19:51:28 -0300, newbie <[EMAIL PROTECTED]>
> wrote, in part:
>
> >Redundancy in using letters.
> >Redundancy in using words.
> >Redundancy in using sentences.
> >etc...
> >So OTP is not surely ( practically speaking) unbreakable.
>
> No, redundancy in plaintext doesn't make the OTP breakable. You can
> imagine the plaintext has whatever constraint you like - but all
> plaintexts of the correct length and meeting that constraint remain
> fully and equally possible.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 12:07:29 -0300
Maybe, I'm jabbering. Because I do not have the power to express all my
ideas in english. I'm french speaking ( + 5 others languages).
It does not matter. The more important is to bring ideas.
Thank you for your explanation.
John Savard wrote:
>
> On Tue, 17 Apr 2001 19:57:19 -0300, newbie <[EMAIL PROTECTED]>
> wrote, in part:
>
> >What is yabbing? I did not find it in my humble dictionary
> >I found yaping. Only dog yap. I'm not dog.
> >I'm newbie.
>
> I think he means jabbering, not yapping.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 09:09:53 -0700
Harald Korneliussen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've come up with a way to reinforce passphrases
> against brute-force attacks without memorizing longer
> ones. This may already be in use, but I don't think so
> because it should be configurable and I haven't seen
> anything like that... It's really mostly for PGP but
> it is relevant to everywhere passwords are used, so I
> post it here.
>
> My idea is that upon selecting a password, X bits of
> random data is added to the password. You are not
> informed of what these bits are, nor does the computer
> store them. The computer only stores how many bits
> there are, and brute-forces them every time you enter
> you password.
If it only brute forces the added bits, doesen't this mean that
the true password is stored on the machine so that when the
added bits are correctly guessed, the machine can know to
stop? I guess it could check against a hash of the proper
password + real bits added.
> The reason this is a good idea is: It only adds a few
> bits of security, but it does this at something
> important, something that is the weak link in schemes
> like PGP. Logging in, or signing or what it is you do
> will take slighty longer time, but this will not be
> noticed - you only add so many bits your machine can
> handle efficiently. The slowdown you experience will
> be nothing compared the slowdown an attacker will
> experience. He presumably has much larger computing
> capabilities than you, but now _your_ capabilities
> come into play too.
Password: "dog" Computer adds stuff and hashes "dog#"
and stores hash & forgets "#" . (8 bits added) You enter
your password and the computer hashes your entry along
with every possible 8 bit addition until the stored hash
matches.
It seems like your work is multiplied 256 times when you
log in where the adversarys is increased 256 * each guess.
Isn't this what is called "key stretching"?
It seems that it might help against some kind of off line attack
but if the adversary is sitting at your computer, or has the hash
to check against off-line then he's still just guessing passwords,
albeit at a somewhat slower, but constant rate.
Paul
>
> If there is something wrong with this approach, or if
> it is for some reason impractical, please tell me!
>
> Harald Korneliussen
>
> ______________________________________________________
> Do You Yahoo!?
> Organiser sammenkomsten på http://no.invites.yahoo.com
>
> --
> Posted from web3001.mail.yahoo.com [204.71.202.164]
> via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 12:10:13 -0300
OTP is theorically unbreakable.
You forget the context where the word occur.
I gave some samples in my last post to Mister Savard.
"Douglas A. Gwyn" wrote:
>
> newbie wrote:
> > This theory has to answer why is OTP likely unbreakable. It is not so
> > sure.
> > It is sure only in theory. Because the language domain is not infinite.
> > There is not only redundancy is using the alphabet. There is redundancy
> > in plain-text using. ...
>
> Put simply, you do not know what you're talking about.
> It is *easy* to show that a OTP properly employed provides
> no information to the eavesdropper that he did not already have,
> regardless of source statistics.
> There is a formal theory of information, first brought to public
> attention by Claude Shannon and extremely well developed by now.
> Please go study a lot more before trying to score a breakthrough.
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 12:16:12 -0300
What is important is not to find all the key.
You have to analyse the context of the plain-text.
You are not going to find a word "homo erectus " in business letter. It
is quite impossible.
But dollars yes, company, yes etc...
Algo to decrypt OTP :
- look for words used in the context (business, personal, etc...)
- try to slide the corresponding bit-string on ciphertext until it
matches.
- build the disclose little by little.
If you try to find the key, it is a wrong strategy.
"Douglas A. Gwyn" wrote:
>
> newbie wrote:
> > This theory has to answer why is OTP likely unbreakable. It is not so
> > sure.
> > It is sure only in theory. Because the language domain is not infinite.
> > There is not only redundancy is using the alphabet. There is redundancy
> > in plain-text using. ...
>
> Put simply, you do not know what you're talking about.
> It is *easy* to show that a OTP properly employed provides
> no information to the eavesdropper that he did not already have,
> regardless of source statistics.
> There is a formal theory of information, first brought to public
> attention by Claude Shannon and extremely well developed by now.
> Please go study a lot more before trying to score a breakthrough.
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 18:24:56 +0200
What you propose is basically to make the password verification procedure
more time-consuming. For certain parameter choices this won't make much
difference for the legitimate user, while a brute-force attacker will face a
presumably harder task. There are several methods for achieving this, e.g.,
making the verification procedure more time-consuming by including, say,
1000 iterations of some hash function in it. I believe quite a few
password-based applications include such means. You may want to check PKCS
#5 (http://www.rsalabs.com/pkcs/pkcs-5/index.html) for some methods used in
practice (each with the particular goal of protecting sensitive information
such as an RSA private key).
Jakob
"Harald Korneliussen" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> I've come up with a way to reinforce passphrases
> against brute-force attacks without memorizing longer
> ones. This may already be in use, but I don't think so
> because it should be configurable and I haven't seen
> anything like that... It's really mostly for PGP but
> it is relevant to everywhere passwords are used, so I
> post it here.
>
> My idea is that upon selecting a password, X bits of
> random data is added to the password. You are not
> informed of what these bits are, nor does the computer
> store them. The computer only stores how many bits
> there are, and brute-forces them every time you enter
> you password.
> The reason this is a good idea is: It only adds a few
> bits of security, but it does this at something
> important, something that is the weak link in schemes
> like PGP. Logging in, or signing or what it is you do
> will take slighty longer time, but this will not be
> noticed - you only add so many bits your machine can
> handle efficiently. The slowdown you experience will
> be nothing compared the slowdown an attacker will
> experience. He presumably has much larger computing
> capabilities than you, but now _your_ capabilities
> come into play too.
>
> If there is something wrong with this approach, or if
> it is for some reason impractical, please tell me!
>
> Harald Korneliussen
>
> ______________________________________________________
> Do You Yahoo!?
> Organiser sammenkomsten på http://no.invites.yahoo.com
>
> --
> Posted from web3001.mail.yahoo.com [204.71.202.164]
> via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 18:54:16 +0200
Paul Pires wrote:
> If it only brute forces the added bits, doesen't this mean that
> the true password is stored on the machine so that when the
> added bits are correctly guessed, the machine can know to
> stop? I guess it could check against a hash of the proper
> password + real bits added.
I don't know how the exact algorithm on Unix works but it's
probably the password encrypted with itself or so. Anyway, the block cipher
is used as a one way function. Yes, today one could use a hash function.
With a block cipher you try until the result matches the one in the /etc/passwd.
Of course, it could happen that Passwd1||Salt1 equals Passwd2||Salt2
but it should be easy to calculate the probability of that to happen.
> It seems like your work is multiplied 256 times when you
> log in where the adversarys is increased 256 * each guess.
>
> Isn't this what is called "key stretching"?
Yes. Of course, 16 bits would be entirely possible today.
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 16:39:42 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What is important is not to find all the key.
> You have to analyse the context of the plain-text.
> You are not going to find a word "homo erectus " in business letter. It
> is quite impossible.
> But dollars yes, company, yes etc...
> Algo to decrypt OTP :
> - look for words used in the context (business, personal, etc...)
> - try to slide the corresponding bit-string on ciphertext until it
> matches.
> - build the disclose little by little.
>
> If you try to find the key, it is a wrong strategy.
An OTP is not possible to break since all messages are equally probable.
Tom
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 12:36:29 -0300
You are trying the wrong way.
To store your password it is easy.
You convert it to numeric value p,
You create a function of two variables : sample p = (x^2)*y - x + y -
(y^2) + c
You store in your computer x
You store in a server y and c ( or in your hotmail account )
Anyone who pick your computer can not find the password.
When you need your password you have just to copy-past your extern value
to retrieve your password. And to compute the result.
Chose x and y big numbers ( 100 digits)
That is it.
You may inverse the operation if you are a server. You do not have to
store any password. You store the values that you need to compute to
retrieve the password. You store in client computer the other part.
If any hacker pick the database. He has no way to retieve the passwords.
He has to hack all the client computer to find all the passwords.
Tom St Denis wrote:
>
> "Harald Korneliussen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I've come up with a way to reinforce passphrases
> > against brute-force attacks without memorizing longer
> > ones. This may already be in use, but I don't think so
> > because it should be configurable and I haven't seen
> > anything like that... It's really mostly for PGP but
> > it is relevant to everywhere passwords are used, so I
> > post it here.
> >
> > My idea is that upon selecting a password, X bits of
> > random data is added to the password. You are not
> > informed of what these bits are, nor does the computer
> > store them. The computer only stores how many bits
> > there are, and brute-forces them every time you enter
> > you password.
> > The reason this is a good idea is: It only adds a few
> > bits of security, but it does this at something
> > important, something that is the weak link in schemes
> > like PGP. Logging in, or signing or what it is you do
> > will take slighty longer time, but this will not be
> > noticed - you only add so many bits your machine can
> > handle efficiently. The slowdown you experience will
> > be nothing compared the slowdown an attacker will
> > experience. He presumably has much larger computing
> > capabilities than you, but now _your_ capabilities
> > come into play too.
> >
> > If there is something wrong with this approach, or if
> > it is for some reason impractical, please tell me!
>
> So if I get your system right your password really is "password"+R where R
> is a random bit string nobody stores. The problem is your method relies on
> the total entropy in the two being larger enough. If I used a dorky
> password like "12345" then you will need a large R to compliment it. Ah...
> but a large R means a slower login.
>
> A simpler method is to use a MagStrip thingy where you write a random bit
> string to a card. If you lose your card you revoke the key stored on it...
> simple as that. Best of all you can have a bigger key on the MagStrip and
> not be forced to memorize (or even know) the key.
>
> Tom
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 16:52:54 GMT
On Wed, 18 Apr 2001 12:04:07 -0300, newbie <[EMAIL PROTECTED]>
wrote, in part:
>What some forget is the context where a word occure.
If it's a one-time-pad, that won't help you. Because any word could be
anywhere, there is no clue to progress with. The pad is *random* and
it was never used for anything else, so there is no constraint on its
bits.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
