Cryptography-Digest Digest #183, Volume #14 Thu, 19 Apr 01 16:13:00 EDT
Contents:
Basic AES question (Lou Grinzo)
Re: Crypto question ("Mark G Wolf")
Re: Basic AES question ("Tom St Denis")
Re: A practical idea to reinforce passwords (Ichinin)
Re: Crypto question ("Robert M Best")
Re: Crypto question ("Tom St Denis")
Re: C code for GF mults (Mike Rosing)
Re: All One Polynomail (Mike Rosing)
Re: Crypto question (Bill Unruh)
DL blind signature ("Cristiano")
Re: Reusing A One Time Pad ("Joseph Ashwood")
Re: OTP breaking strategy (newbie)
Re: Prime Numbers Patterns? (Bill Unruh)
Re: "UNCOBER" = Universal Code Breaker (newbie)
Good Schools of History and Informatik (Compter Science) (Frank Gerlach)
Re: OTP breaking strategy (newbie)
Re: OTP breaking strategy (newbie)
Re: Crypto question ("Joseph Ashwood")
Re: Reusing A One Time Pad ("Mark G Wolf")
Required Reading (Frank Gerlach)
Re: Any unbroken knapsack cryptosystem? ("JamesBaud")
Re: C Encryption ("JamesBaud")
Re: Reusing A One Time Pad ("Paul Pires")
Re: "UNCOBER" = Universal Code Breaker ("Joseph Ashwood")
Thanks for all replies reg:passphrase salting
(=?iso-8859-1?q?Harald=20Korneliussen?=)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Lou Grinzo)
Subject: Basic AES question
Date: Thu, 19 Apr 2001 16:17:16 GMT
I'm just starting to learn about AES, and I was wondering:
Why does the AES standard support only the key sizes of
(I think) 128, 192, and 256 bits? Is it purely to keep
the specification and logistical issues simple? Or is there
a technical reason, such as increasing the key size doesn't
make AES any more difficult to attack? (I know that last
one sounds goofy, but in a world where PKI works, almost
anything is possible. <g>)
Lou
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Thu, 19 Apr 2001 11:21:47 -0500
> So either the private or the public key can be used to decode a a message
> encoded with the other. This was something I didn't catch from the RSA
> specs.
Just remember to keep one and the same key of your pair always secret.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Basic AES question
Date: Thu, 19 Apr 2001 16:23:22 GMT
"Lou Grinzo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm just starting to learn about AES, and I was wondering:
> Why does the AES standard support only the key sizes of
> (I think) 128, 192, and 256 bits? Is it purely to keep
> the specification and logistical issues simple? Or is there
> a technical reason, such as increasing the key size doesn't
> make AES any more difficult to attack? (I know that last
> one sounds goofy, but in a world where PKI works, almost
> anything is possible. <g>)
Those keysizes were chosen as 128-bit = low, 256 = high and 192 = medium.
Although that's a bit naive. 128 bit keys are hardly "low security" by any
forseeable standards... (unlike factoring or DLP brute force is fairly
straight forward...)
Note that Rijndael (i.e AES) supports diff keysizes. Others like RC6
supports virtually any key size including the AES required...
Tom
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: A practical idea to reinforce passwords
Date: Mon, 16 Apr 2001 16:23:02 +0200
Tom St Denis wrote:
> > 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.
Unix systems stores the accounts in /etc/passwd,
and the hashes are stored separately in /etc/shadow.
Note: No system (should) use encrypted passwords, if
encryption is used the passwords are wide open to a simple
comparison attack, whereas if you hash(passwd + salt) you
have to break every password. IIRC, even M$ have figured
this out for Win2k, NT4 passwords are not salted, that's
why Lophtcrack have such a good performance.
(OTOH - Passwords storage for Win 95/98 == Joke.)
Regards,
Ichinin
------------------------------
From: "Robert M Best" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Thu, 19 Apr 2001 07:47:51 -1000
> The security of RSA is directly related to the modulus
> size. The ciphertexts will be as large as the RSA
> modulus. Thus, small plaintexts will have fairly large
> ciphertexts. That's life.
Do other public-key cryptosystems besides RSA have that disadvantage? Is
there a PKC where the ciphertext is as small or almost as small as the
plaintext message, even though the private and public keys may be thousands
of bits?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Thu, 19 Apr 2001 17:54:28 GMT
"Robert M Best" <[EMAIL PROTECTED]> wrote in message
news:9bn89l$31sm$[EMAIL PROTECTED]...
> > The security of RSA is directly related to the modulus
> > size. The ciphertexts will be as large as the RSA
> > modulus. Thus, small plaintexts will have fairly large
> > ciphertexts. That's life.
>
> Do other public-key cryptosystems besides RSA have that disadvantage? Is
> there a PKC where the ciphertext is as small or almost as small as the
> plaintext message, even though the private and public keys may be
thousands
> of bits?
This comes up often.... arrg.
If you have a n-bit RSA modulus your plaintext and ciphertext are always
n-bit integers. Regardless of leading zeros, you may be able to represent
them with smaller bit integers but that's not the point.
Note that ElGamal which is more difficult to solve has ciphertexts twice the
size of the plaintext...
I think RSA is rather efficient in it's usage of bandwidth in this respect.
Tom
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: C code for GF mults
Date: Thu, 19 Apr 2001 13:01:48 -0500
Jyrki Lahtonen wrote:
> Define elements x_i recursively as follows:
>
> x_0=1, and
>
> for i>0 let x_i be a root of the equation
>
> T^2+x_{i-1}T+1=0 (*)
>
> It is relatively straightforward to see that x_k then generates
> (but is not primitive by a long shot) the field GF(2^(2^k)).
> If memory serves me right, it even generates a normal base.
It ain't straight forward for me, but let's see if I can get it
eventually. For x_1 we have
x_1^2 + x_1*x_0 + 1 = 0
You're saying x_1 has to be 4 bits wide. Since x_0 = 1, we have
a very simple quadratic, but to solve it in GF(anything) we need
pick (anything) first. Depending on what we pick, how do we know
it's always 4 bits?
In the complex plane, T = (-1 +/- sqrt(-3))/2. This lies on the
unit circle at 45 degrees, so it's the 4th root of unity. Is that
how you figure the field size?
Is T always the 2^k th root of unity if you use the 2^(k-1) root as
a coefficient? Pretty cool :-)
I still don't quite understand how you pick the basis tho.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: All One Polynomail
Date: Thu, 19 Apr 2001 13:07:37 -0500
Andre Kim wrote:
>
> I'd like to know the property of all one polynomial for irreducible
> polynomial over GF(2^m). If you have any knowledge, book, or article, please
> let me know.
> Regards!
Joe Silverman wrote a very nice paper for CHES '99 which describes it. He
found some previous references and lists them there as well. I think you
can find it under the Springer LNCS series, or maybe floating around the
net. If not, I've got a paper copy I can mail you.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Crypto question
Date: 19 Apr 2001 18:31:48 GMT
In <9bm35m$2r6a$[EMAIL PROTECTED]> "Robert M Best"
<[EMAIL PROTECTED]> writes:
>I'm have not been able to find real-world examples of RSA. Since the
You have not looked very hard. Just one example-- PGP
>modulus n is the product of two large primes, don't both the public key
>(n,e) and private key (n,d) have to be really large numbers like a thousand
>bits or so? And how small can the "message" be before RSA becomes
Yes. they must be large.
>impractical? DES can securely encrypt/decrypt a message of 64 bits with a
One bit.
>key of only 56 bits. Can RSA do that? If RSA encrypted a message of 64
Well how secure DES is is open to question, but DES is a system where
all keys must be kept private. If that is what you want, use a secret
key system. If you want a public key system, you must use a very large
key. (The public key gives away a huge amount of information so the key
must be long to compensate).
>bits, would a typical RSA public key be a thousand bits or so even though
>the message is only 64 bits?
Thousands of bits. You could use RSA with 5 bits, but it would not be
very strong.
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: DL blind signature
Date: Thu, 19 Apr 2001 20:31:41 +0200
In many systems (or perhaps in all) for the blind signature based on DL, one
must choose a prime q that divides p-1 (also p is prime) and then a
generator in the moltiplicative group Zq* (cfr Chaum-Pedersen from paper
"Loyalty Program Scheme
for Anonymous Payment Systems" by Arrianto Mukti Wibowo and Kwok Yan Lam).
Doing some trials with small numbers, when I compute the public key y=g^a
mod p (a is my private key) for all a<p, the distribution of y may be very
bad; on the contrary, if I compute y=g^a mod q for all a<q, the distribution
is as expected: I get all the elements in Zq* (g is a generator!).
Why this "strange" set up?
My implementation of the algorithm in the above paper at page 13
(Chaum-Pedersen blind signature) doesn't work. The modulo for all the
calculations is not shown. Is it always mod p or mod q?
A last question. At step 3 there is: choose u in Zq* and v in Zq. q is
prime, what is the difference?
Thanks
Cristiano
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 11:10:29 -0700
You're going about it the wrong way. It's a very common mistake and one that
I made for quite some time. The way out that I found is I started thinking
of the pad in entropic terms, whether it is 0 or 1 makes no difference, only
the amount of content in the pad. By moving over to entropy based estimates
of the strength you very quickly see that although given the pad you can
find collisions, those collisions are themselves information, information
that the attacker cannot know because the distance between the collisions is
random. I encourage you to stop thinking of the pad in terms of a series of
bits, and start thinking of it as a series of entropic values, it will make
seeing the security in the OTP much easier, it will also make judging stream
ciphers much easier because the natural judgement will be apparent entropy.
Joe
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bms5e$1kl8$[EMAIL PROTECTED]...
> > The "reusing" scheme:
> > Mark G. Wolf thinks it's realistically unbreakable
>
> It's more than a scheme. If I had an "infinitely" large crypto-doodle
pad,
> or even a "very" large one, I could find sections of various sizes that
> repeat or match, yet my security would not be compromised according to
your
> own belief. So what gives? Obviously it comes down to the predictably
of
> my use of it.
>
>
>
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 14:31:19 -0300
Yuo have yet a plagiat's Nobel Prize. Did you read the article about
Ideal homophonic system?
Mok-Kong Shen wrote:
>
> Volker Hetzer wrote:
> >
> > newbie wrote:
> > >
> > > It is hard to break OTP but not impossible.
> > > Let me explain my strategy. You think that I do not know what I'm
> > > talking about.
> > Right.
> > Now, here's your chance of getting the nobel prize in maths:
> [snip]
>
> He might decline on the ground that there is no Nobel prize
> in maths. But I believe that plenty of readers of the group
> would be ready to donate some money to form a very
> attractive prize for his sensational success of breaking
> the OTP.
>
> M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Prime Numbers Patterns?
Date: 19 Apr 2001 18:37:07 GMT
In <9blb44$js6$[EMAIL PROTECTED]> "AY" <[EMAIL PROTECTED]> writes:
]Also, something that everyone should know (but not discussed in HAC!) is
]that the digits of a multiple of 3 always add up to a multiple of 3 (think
]recursion). I just wonder if there's a big list of such curiosities
]somewhere?
That is not a property of the number but of the representation of the
number. In base 11, this feature of multiples of 3 does not work.
(Note that most people did learn this in grade 5 or so).
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Thu, 19 Apr 2001 14:38:17 -0300
All the messages does not all have the same probability to be valid
given the context
If you have as output any word out of context you can eliminate it.
You may decrypt it little by little.
You can eliminate 95% of the messages.
The goal is not to recover the key.
You have just to compute the probability that the output is random and
if it satisfies Maurer conditions or other statistical tests.
If the message is 100101010
and the ouput 1111111111
you are quite sure to reject the "possible" key.
Tom St Denis wrote:
>
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Tom St Denis wrote:
> > > An OTP is not possible to break since all messages are equally
> > > probable.
> >
> > No! No wonder the newbie is so confused.
>
> What? All solutions are equal probable since all keys are equal probable.
> That's why the OTP is secure.
>
> Tom
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Good Schools of History and Informatik (Compter Science)
Date: Thu, 19 Apr 2001 20:43:07 +0200
Although not directly related to cryptography, good education is the
foundation of cryptanalysis.
I can recommed Mr Gebhardt of www.ba-stuttgart.de. Excellent
out-of-the-box-thinking.
At the same time extremely coherent.
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 14:46:31 -0300
When you introduce the context factor all the messages are not
equiprobable.
That is the way to try to find out the input.
If I analyse any output of 128 bits I will obtain 2^128 messages. I know
that.
But all the messages are not 100% in the context.
And all the output are not 100% random.
I have two ways to select : context factor and degree of randomness.
Samuel Paik wrote:
>
> You simply don't understand a one time pad. Every word will match at
> every position for some bitstring.
> --
> Samuel S. Paik | [EMAIL PROTECTED]
> 3D and digital media, architecture and implementation
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 14:48:25 -0300
But every word is not valid given the context.
And every output is not necessarly (100 %) truly random.
Samuel Paik wrote:
>
> You simply don't understand a one time pad. Every word will match at
> every position for some bitstring.
> --
> Samuel S. Paik | [EMAIL PROTECTED]
> 3D and digital media, architecture and implementation
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Thu, 19 Apr 2001 11:39:37 -0700
The only reason for using large primes is the difficulty of factoring
increaseas the length grows. RSA will work if you use the primes 3,5, it
will just be extremely easily factored.
How much of the block needs to be filled for security is a question that we
can't answer completely yet. What we can say is that using OAEP for
encryption seems to be good, and using PSS for signing seems to be better.
We also know that the security decreases as the values get smaller, with 1
and 0 having constant encryptions. The best advice I can give is to use OAEP
for encryption and PSS for signing. Whether or not you will be able to
reduce the output size after encryption, if you only encrypt a small amount
is a hard question, if you use a full size e then the answer is usually no
(exception 0,1), however if you use a small e, then it may be possible to
not reach the full size. Overall approximately half the time you will be
able to drop 1 bits, 1/4 2bits, 1/8 3, 1/2^n n, so I wouldn't bet on being
able to reduce the output size, but I'd bet against you being able to reduce
it by more than 1 bit.
You really shouldn't use RSA as a replacement for
DES/AES/Twofish/3DES/Serpent/IDEA/etc they really are not comparable. RSA is
absurdly slow to be used to encrypt in bulk. OTOH symmetric ciphers (e.g.
the list above) do not have the ability to distribute a public key to
everyone, you would instead have to share a secret before you could
communicate. They really do target seperate uses.
Joe
"Robert M Best" <[EMAIL PROTECTED]> wrote in message
news:9bm35m$2r6a$1@newssvr05-
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 14:01:19 -0500
I've got it! No not Mad Cow Disease, better. I think I've got the makings
of an "infinitely" reusable cryptodoodle pad. At least the underlying frame
work. And I think it should work very well and is quite robust. I just
wish I knew something about cryptography. It's actually pretty freaking
simple, and amazingly enough not unlike famous cipher systems of the past.
Just goes to show it's all been done before, mostly. The big boys at the
NSA must know this stuff. Hey if you don't I let you know for a large sum
of cash.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Required Reading
Date: Thu, 19 Apr 2001 21:07:01 +0200
Chaitin on Mathematics, Randomness and Phantasy:
http://www.cs.auckland.ac.nz/CDMTCS/chaitin/bard.html
------------------------------
From: "JamesBaud" <[EMAIL PROTECTED]>
Subject: Re: Any unbroken knapsack cryptosystem?
Date: Thu, 19 Apr 2001 12:30:11 -0500
Consider the "knapsack" method to be broken, as almost every large & small
algo has been
broken or sneered on...
{ref: Applied Cryptography, Bruce Shneier}
-- JamesBaud
"mklai" <[EMAIL PROTECTED]> wrote in message
news:96mpsi$99c$[EMAIL PROTECTED]...
> I am a novice.
>
> Are there any unbroken knapsack cryptosystems?
>
> Serge Vaudenay claimed to break the Chor-Rivest system (see his article in
> Lectures Notes in Computer Science - Crypto '98, the same article also
> appears in Journal of Cryptology 2000). Is now the consenus that
Chor-Rivest
> is considered broken?
>
> Thanks.
>
>
>
>
------------------------------
From: "JamesBaud" <[EMAIL PROTECTED]>
Subject: Re: C Encryption
Date: Thu, 19 Apr 2001 12:39:36 -0500
lol... he fixed your worthless code...
-- JamesBaud
"Steve Portly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Small modification, you had a memory leak that could give access to your
pass phrase.
> :-)
>
> Jan Panteltje wrote:
>
> > On a sunny day (15 Apr 2001 16:32:18 -0600) it happened
[EMAIL PROTECTED]
> > (Ben Cantrick) wrote in <9bd7hi$[EMAIL PROTECTED]>:
> >
> > >In article <hWlC6.42589$[EMAIL PROTECTED]>,
> > >Logan Raarup <[EMAIL PROTECTED]> wrote:
> > >>Anyone know how to encrypt a string in C?
> > >
>
> #include <stdio.h>
> char inStr[17];
> int count;
>
> >
> > >
> > >void main(void)
> > >{
> > >/* char inStr[17]; Gratitous buffer overflow error
part 1. */
> > >
> > > printf("Enter the string to be encrypted: ");
> > > gets(inStr); /* Gratitous buffer overflow
error part 2. */
> > > printf("The string encrypted is: ");
> > > printf("djlkakjfdLI3nklFD9Fklklfasj(3jmklFD3#@23jklas;j(32lkjr*");
> > > printf("\n");
>
> printf("\nMemory containing pass phrase which will be swapped to
disk\n");
> for (count = 0; count < 17; count++)
> printf("%c", inStr[count]);
> printf("\nLets overlay this array before we exit the program\n");
> for (count = 0; count < 17; count++)
> {
> inStr[count] = '0';
> printf("%c", inStr[count]);
> }
>
>
> >
> > > return(0);
> > >}
> > >
> > > This encryption program has perfect security - the output is
essentially
> > >random and has no dependecy whatsover on the input.
> > >
> > > But you're going to have to figure out the decryption routine on your
own. ;]
> > >
> > >
> > > -Ben
> > >--
> > >Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs
still suck.
> > >BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
> > >The Spamdogs: http://www.dim.com/~mackys/spamdogs
> > >"I don't think so," said Rene Descartes. And then he vanished.
> > >
> > Yes, but it is not user friendly,
> > printf("This is the encrypted string with a truly random OTP\n");
> > is a lot better.
> > I always use this, end select the OTP accordingly, since it has to
change
> > anyways.
> > Message should be shorter then the above text of cause.
> > ;-)
> > Over to you
>
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 12:21:20 -0700
Mark G Wolf <[EMAIL PROTECTED]> wrote in message
news:9bncnn$5qoe$[EMAIL PROTECTED]...
> I've got it! No not Mad Cow Disease, better. I think I've got the makings
> of an "infinitely" reusable cryptodoodle pad. At least the underlying frame
> work. And I think it should work very well and is quite robust. I just
> wish I knew something about cryptography. It's actually pretty freaking
> simple, and amazingly enough not unlike famous cipher systems of the past.
> Just goes to show it's all been done before, mostly. The big boys at the
> NSA must know this stuff. Hey if you don't I let you know for a large sum
> of cash.
Look, Of course you can re-use the CONTENTS of a one time pad.
The're just bits (0,1). You cannot re-use the organization of bits of said
pad in any definable or predictable way without loosing the only thing
about a one time pad that's interesting. It's provable security. You have
violated a constraint of the proof.
If you reuse the contents by some complex pick and place, doodle
and swap or anything other than Carnak divination, You must comunicate
this process to the recipient or he cannot decode it. You have just moved
key from the pad to the scramble instructions.
You think it could be strong? Fine. You just joined the clammoring
multitude who have unsupportably unbreakable encryption. There
isn't anything new or controversial. No-one is so jealous of your
brilliance that we are trying to divert you from your percieved truth.
You're shooting yourself in the foot and sometimes it's just too
painful to watch without a plea for mercy.
Paul
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Thu, 19 Apr 2001 12:29:07 -0700
You don't seem to fully understand this. There is a set of possible
messages, each with it's own real probability. While the attacker can
discard all messages that are not among that set, the attacker CANNOT
determine which of that set the encrypted values maps to. That cannot is a
mathematical statement, you cannot violate it. If you would like to try, I
will even give you a better position than necessary, I'll give you a small
PGP encrypted file, all you have to do is tell me what I said. To make it
even more fair it begins with :
The secret phrase is :
the next part is a misquoting of a famous line followed by a simple
statement. Both the secret phrase and the statement are from latin, one if
the bad misquoting of Julius Ceaser, the second an actual quote. Because
it's so small, I've attached it. I fell this is a fair system, after all
there exists a OTP that translates it to what it was originally, so this can
be no stronger than a OTP, and it is known to be much weaker. In case you're
tempted to try to brute force the passphrase, don't bother it's got more
entropy than could be used.
Since I already know you won't be able to find the OTP to map the test
encryption to the complete real text, I will take this opportunity to
declare victory. Of course if you succeed there's always the fact that it's
not even a full OTP. I suppose in fairness I should tell you exactly how
many characters were in the original (since PGP does some compress and
expansion), 63 bytes, all standard readable ASCII (except the <enter> and
<space>).
Joe
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> All the messages does not all have the same probability to be valid
> given the context
>
> If you have as output any word out of context you can eliminate it.
> You may decrypt it little by little.
> You can eliminate 95% of the messages.
> The goal is not to recover the key.
> You have just to compute the probability that the output is random and
> if it satisfies Maurer conditions or other statistical tests.
>
> If the message is 100101010
> and the ouput 1111111111
> you are quite sure to reject the "possible" key.
>
>
> Tom St Denis wrote:
> >
> > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Tom St Denis wrote:
> > > > An OTP is not possible to break since all messages are equally
> > > > probable.
> > >
> > > No! No wonder the newbie is so confused.
> >
> > What? All solutions are equal probable since all keys are equal
probable.
> > That's why the OTP is secure.
> >
> > Tom
begin 666 Text.txt.pgp
MJ -01U###00#`P)-`7]BP8]82V#)8V@%PO-0N'!AF8A[WR@>DP-M>>[S@,=C
M]<>MFN7E@X_X7$G]&V0OX/%2-H_K*_=^90E'5\;,)K,;WK3X+2=X=0SR'L"Y
?-,OP6ED79=W6^CTH3;CSN+CSC:I\RZQA)G(4:G/09 ``
`
end
------------------------------
From: [EMAIL PROTECTED] (=?iso-8859-1?q?Harald=20Korneliussen?=)
Subject: Thanks for all replies reg:passphrase salting
Date: Thu, 19 Apr 2001 19:40:04 +0000 (UTC)
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Hello, I'd like to thank all of you for the feedback.
I appreciate the criticism, but I don't quite
understand:
The password scheme I'm talking about is the one with
the hash of the entered password being compared to the
hash of the correct password, which is stored on the
machine (the hash, not the password). I though it was
this way all password verification was done, isn't it?
You see that though the demands on the defending
computer increases, the demand on the attacking
computer increases exponentially(?) more because the
problem of finding the password AND the "salt" is much
more difficult than taking the problems one after the
other. (If you know the answer to one of the problems,
the passphrase, you _can_ take them one by one, of
course)
I have been loath to pull in actual numbers, because
to be frank I have no ideas how many passwords a given
machine can check per second. But it was stated in a
reply that 16 bits of salt should pose no problem for
normal machines, so let's take that as an example.
Now, say your password is eight random hexadecimal
characters. That should be ... 16^8 = 4.294.967.296
different possible passwords. (ugh, you can't even cut
and paste from the windows calculator)
Now I've heard of chips that can try 1.000.000 DES
keys pr second so this isn't a safe password.
Now, let the "salt" be two random hexadecimal numbers.
That is 16*16 = 256 different possibilities. That is
nothing to bruteforce, but only the person who knows
the password chan bruteforce it separately. The
attacker has to bruteforce it along with the eight
characters of the password, giving 265*4294967296=
1.099.511.627.776 . So in short those few bits are
just 256 different tries for you, but for the attacker
the same few bits are a lot more. That's the nature of
those things :-)
So you see, it's a lot more than simply slowing things
down. On a remote login things would get a little
different of course, perhaps there's a way there too
but I can't think of one right now.
It was objected that anything that slows down
encryption is a bad thing. True, but this enforces
what is often the weakest link - I don't immediately
see other ways to do it without involving the user
(but carrying part of your password on a disk was a
good idea)
And of course you still have to choose a strong
passphrase. But you get more in return - exponentially
more I believe, because each bit doubles the security
that was there before. How many of you have PGP
passwords with are provably more secure than the other
elements in the cryptosystem? It should be easier to
get that with this system.
Yours truly, Harald Korneliussen.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use
<http://www.pgp.com>
iQA/AwUBOt8xKXVDGcMjjSaQEQJQswCfcSwQSoj/EJ3b0YOfUH3inhKc2mgAoOdM
atqdVSROuvzjItfth8Pqv1dC
=V9/V
=====END PGP SIGNATURE=====
______________________________________________________
Do You Yahoo!?
Organiser sammenkomsten på http://no.invites.yahoo.com
--
Posted from web3006.mail.yahoo.com [204.71.202.169]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
** 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
******************************
