Cryptography-Digest Digest #78, Volume #11 Wed, 9 Feb 00 06:13:01 EST
Contents:
How is twofish different from blowfish ? ([EMAIL PROTECTED])
Re: Anti-crack (Vernon Schryver)
Re: New standart for encryption software. ("finecrypt")
Re: (Anthony Stephen Szopa)
Re: New standart for encryption software. ("finecrypt")
Re: Factorization (David Nelson)
reedtestreed (Anthony Stephen Szopa)
Re: New standart for encryption software. (Johnny Bravo)
Re: question about PKI... ("Joseph Ashwood")
Re: How is twofish different from blowfish ? ("Joseph Ashwood")
Re: I'm returning the Dr Dobbs CDROM (Simon F)
Guaranteed Public Key Exchanges (No Brainer)
Re: How secure is this method? What about this? (Mok-Kong Shen)
Continually Secure Password/Pin ([EMAIL PROTECTED])
Question about DSA signature (Safuat Hamdy)
Re: Hill Climbing ("Michael Darling")
Re: Continually Secure Password/Pin (Paul Rubin)
Re: Question about DSA signature (Scott Contini)
Re: Anti-crack (Sisson)
Re: Continually Secure Password/Pin ("Lyal Collins")
Continually Secure Password/Pin (Gary)
Re: Anti-crack (Troed)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: How is twofish different from blowfish ?
Date: Wed, 09 Feb 2000 06:17:30 GMT
Hello...
The subject pretty much covers it. How is the cipher which has been
submitted as a candidate for the advanced encryption standard called twofish,
different from blowfish ? Thanks in advance.
Spike Ivans
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Anti-crack
Date: 8 Feb 2000 16:25:23 -0700
In article <AG_n4.142$[EMAIL PROTECTED]>,
John E. Kuslich http://www.crak.com <[EMAIL PROTECTED]> wrote:
>I have now read the article and I do NOT recommend it.
>
>I found it superficial and sometimes offered silly suggestions...
>There are very excellent sources of better advice and information ...
> ... They require some Net searching skill to find. :--)
>
>Anyone with adequate motivation and skill ... ... will
>easily find them.
That applies to most computer trade rag inter-ad filler on any topic.
When you find an trade article informative, an alarm should sound warning
that you probably know even less (i.e. a lot that is false) than the little
that you knew before reading the article. Only if you started completely
ignorant, you forget most of what the article says, and you remember that
you still know practically nothing can you hope to come out ahead.
The only text in the trade rags that is even slightly reliable is in the
ads, because of the consequences of false advertising. It's not as if
trade rag articles are peer reviewed, unless you count sales people.
Consider who has time to write for a trade rag. Most of the inter-ad
filler that is not produced by unvarnished sales people is written by
consultants who have the time to spare writing for free or next to free,
or by new-grads hired into what the trade rags are pleased to call labs
for salaries and options commensurate with working for a trade rag.
I suspect that if I knew anything about any other field that has trade
rags, I'd say the same about that field's trade rag inter-ad filler.
As for that particular article, some of the other suggestions are as good
as its advice to write bad code. Consider its suggested encryption for
strings, 'ANDing with a constant eight-bit "key"'. Yes, "ANDing"! That's
only a little less silly with "XOR", since no rocket science is needed
to pipe an image 255 times through something that xor's with a constant
before piping to the `strings` command. Never mind that in embedded
code you often have the obvious reason to use denser encodings than 1
char/byte. Or that a lot of embedded code doesn't have access to a lot
of alphanumeric output and so has less use for lots of ASCII text.
....
I wrote the preceding before reading today's mail. Surveying the
nonsense in today's crop of trade rags reminded me that particular
rag is not as bad as many others. I try to keep up with some rags to
see newly advertised products and what the credulous "know" this month.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: "finecrypt" <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 9 Feb 2000 09:28:11 +0300
> This is hardly something that sets a "new standard", the current
>standard specifies that source code be available for peer review to ensure
>proper implementation and security. You don't even meet the current
>standard, much less set a new one. As for your claims of
>
Dear Johnny,
why you need source code, if you can test FineCrypt with test vectors?
Download program and read online help about of how you can get a guarantie
of reliable encryption. Try it.
http://www.finecrypt.com/fcinst.exe
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re:
Date: Tue, 08 Feb 2000 22:15:15 -0800
"C. Prichard" wrote:
>
> I prefer to think that a large number of NSA employees are infiltrating internet
>CHAT groups to intercept secret information as it is being exchanged.
>
> -C. Prichard
If you use secure encryption none of this matters: The NSA / CIA
cannot decrypt it to see any "watermark(s)."
------------------------------
From: "finecrypt" <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 9 Feb 2000 09:43:58 +0300
More comments about FineCrypt from crypto gurus will be appreciated.
Thanks.
------------------------------
From: [EMAIL PROTECTED] (David Nelson)
Subject: Re: Factorization
Date: Wed, 09 Feb 2000 07:16:41 GMT
On Fri, 4 Feb 2000 21:22:53 -0700, Jerry Coffin <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>> Hello. Would someone please run 5154228018862208512867 through a math package
>> and tell me:
>> - its factors (2 primes roughly the same size - RSA, you guessed it)
>
>PRIME FACTOR 53401798669
>PRIME FACTOR 96517872943
>
>> - the name of the math package (any will do, Mathematica, whatever)
>
>The free "factor.exe" used to demo the MIRACL math package.
Where can I download it?
>
>> - how long the factorization took
>
>Half a second.
>
>> - what system, roughly, it was run on (P2 400Mhz, say)
>
>Your guess of a P2/400 was right on the money. Of course, if I hadn't
>been running an ECDL program in the background, this might have been
>done in .4 seconds instead... <G>
>
>--
> Later,
> Jerry.
>
>The universe is a figment of its own imagination.
The only reason the US doesn't have a Gestapo is that the
FBI, BATF, DEA, EPA etc. can't speak German.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: reedtestreed
Date: Tue, 08 Feb 2000 23:03:24 -0800
reedtestreed
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 09 Feb 2000 02:53:54 +0000
On Wed, 9 Feb 2000 09:28:11 +0300, "finecrypt" <[EMAIL PROTECTED]>
wrote:
>Dear Johnny,
>
>why you need source code, if you can test FineCrypt with test vectors?
Because there is no way to know if the test vectors are the same part of
the program that is used to encrypt the data, there could be any number of
weaknesses either intentional or not inside such a program. For all I
know the test vectors are just that, a separate part of the program that
fools people into thinking that the program is secure.
>Download program and read online help about of how you can get a guarantie
>of reliable encryption. Try it.
The guarantee is worthless. If I can't see how it works I end up with a
black box, and bad crypto output looks just like good crypto output.
What are you offering, your money back if a foreign government tortures
and kills a citizen who thought your product was safe? I'll pass and
stick with alternatives that I can inspect completely and are completely
free. If I'm going to be encrypting files on my computer I'm not going to
encrypt them one file or even one folder at a time, much easier to create
a Scramdisk partition which encrypts everything put into it on the fly.
Johnny Bravo
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: question about PKI...
Date: Wed, 9 Feb 2000 00:03:25 -0000
> Actually I was wondering if it was useful to use SRP in
PKI solutions. Such a
> secure protocol must be helpful for downloading a
private-key on line
>
> Is there anyone who thought about this?
Well considering that I was the one that suggested it to
you, I'd have to say that at least one of us has.
It has some flaws in the logic because SRP makes use of PK,
it's useful in order to allow arbitrary authenticated
communication, very much like Kerberos.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: How is twofish different from blowfish ?
Date: Wed, 9 Feb 2000 00:10:24 -0000
> The subject pretty much covers it. How is the cipher which
has been
> submitted as a candidate for the advanced encryption
standard called twofish,
> different from blowfish ? Thanks in advance.
About the only similarities are the secind half of the name
and authorship.
Joe
------------------------------
From: Simon F <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Wed, 09 Feb 2000 08:29:19 GMT
In article <[EMAIL PROTECTED]>,
Victor Zandy <[EMAIL PROTECTED]> wrote:
>
> A couple weeks ago I asked for opinions of the Dr Dobbs CDROM
> collection of cryptography books. Overwhelmingly the response was
> positive, so I bought it. (Thanks again to those of you who replied.)
>
> I am returning the CDROM because it is not suitable for printing.
> For example, to print chapter 1 of the Stinson book (44 pages) Adobe
> acroread (x86/Solaris 2.6) creates a 500MB postscript file. I cannot
> print this file directly, probably because it is too big. Although I
> might be able to find a way to print the file, at 500MB it would take
> too much time.
Can't you get hold of Ghostscript?
I believe it allows you to select particular pages for printing.
I admit I don't know if it will handle a 500mb file, but it may be
worth trying.
There are windows and unix versions.
Simon
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Guaranteed Public Key Exchanges
Date: Wed, 09 Feb 2000 17:07:39 +0800
Does anyone know of a secure way to exchange public keys between two
people via the Internet (e-mail) without using any other form of
communication?
Also, would the proposed system work if *someone* was intercepting and
modifying the key exchanges?
TIA.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: How secure is this method? What about this?
Date: Wed, 09 Feb 2000 10:38:12 +0100
Xcott Craver schrieb:
>
> Erik <[EMAIL PROTECTED]> wrote:
> >
> >1) Get a number from A, Na, from 1 to 32,
> >2) Get a number from B, Nb, which is Na bits long.
> >3) XOR the next Na bits of plaintext with Nb.
> >and repeat
>
> This is identical to just XORing all of the second stream with
> the plaintext. Unless I'm reading you wrong.
Exactly here you were wrong, see below.
> Seems to me that the exact same XORs will be made with the
> exact same bits from B. Hence, this is a stream cipher using
> B as a pseudo-random number generator.
Inference of B needs generally to know how many bits of each output
of B are used. This, however, is varaible, being determined by A.
The analyst has to determine (successively) which 'group' of bits
of the ciphertext are the result of XORing the plaintext bits using
one 'single' number output from B. Here lies the main difficulty.
(There can also be variants of the ways of obtaining the required
bits from the output of B, i.e. not necessarily taking from it in a
'constant' fashion, thus further confounding the analyst.)
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Continually Secure Password/Pin
Date: Wed, 09 Feb 2000 09:27:26 GMT
When creating and using a user/password account on the web why isn't
the following method used:
Client types in user name and password, clients computer sends server
user name and the one millionth iterative one way hash of the password.
Server creates user name and stores said hash.
When logging on first time user sends user name and the 999,999th
iterative hash of the password. Server authenticates by hashing this
and comparing it to last stored hash. On acceptance it allows access to
account and updates servers hashed password to the new 999,999th
iteration.
Next time user logs on he uses the 999,998th iteration and so on.
No eavesdropper can imitate the user on future login sessions.
Server uses little processing time as it only needs to hash once.
A variation of the system can be used to authenticate non certified
telephone conversations (secure or insecure). 2^24 iterated hashes of
passwords and associated user id could be stored on a public server.
This represents the authenticity of user at the time of posting on the
server. To authenticate at a time after that, the person wishing to
confirm their id publishes the (2^24-((time-servertime)seconds))th
iterative hash. This can be confirmed by access to the public server.
It also can be used too in credit card/cheque authorisations etc.
I've searched to see if a similar system has been proposed before but
couldn't find it. If it does, could someone give me pointers?
Gary. At ArchRivals.F9.Co.UK
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Question about DSA signature
Date: 09 Feb 2000 10:25:35 +0100
Hi,
Let p be a prime, q another prime such that q | (p - 1), let 1 < a < q, let
gamma be an element of Zp* of order q and alpha = gamma^a.
The signature step of DSA is, select a random k such that 1 < k < q and
compute
r = (gamma^k mod p) mod q
s = k^(-1)(h(M) + a r) mod q
the signature is(s, r).
Q: Why is the r in the equation for s necessary, i.e. why can't one compute
s = k^(-1)(h(M) + a) mod q
(and adjust the verification step appropriately, of course). Would this be
less secure?
--
S. Hamdy | All primes are odd except 2,
[EMAIL PROTECTED] | which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
------------------------------
From: "Michael Darling" <[EMAIL PROTECTED]>
Subject: Re: Hill Climbing
Date: Wed, 9 Feb 2000 09:49:37 -0000
Hi Mark, thanks for popping you head in.
Thanks also for giving some pointers on how to mutate.
I spent last night getting the trigraph dictionary right for speed (getting
a balanced binary tree) so I sort
of got side tracked. I'm kind of glad I did because there is a lot more
info to go on this morning.
The Singh book has led to a great deal of interest in GA and Hillclimbing -
a lot of knowledge being understandably
jealously guarded while the challenge goes on. I'm looking forward to
someone completing the challenge. Maybe
Jim Gillogly who I see has contributed a good post below, or Andrew Plater
are even now making a breakthrough.
When that happens I would hope that Singh in collaboration with the eventual
winner would write an article detailing how each
stage was broken.
When the challenge is broken I hope to see a good deal of discussion and
swapping of code and ideas in this area.
Regards,
Mike.
> My mutation operators were:
> do nothing...
> swap a row...
> swap a column...
> swap two letters...
> replace the square with a random new one...
> and "optimize".
>
> Optimize is a procedure which iteratively selects the best pair of
> letters in a
> square and swaps them until no further improvement can be made. This
> procedure
> was invoked very seldom (1/1000), but without it the method converges
> rather slowly.
> Doing it more often may cause it to converge in fewer generations, but
> it is
> expensive enough that it doesn't help get the result in any less wall
> clock time.
>
> My GA was entirely mutation based, never could figure out how to make
> crossover work.
>
> You can experiment with percentages on which mutation operation to
> perform, I basically
> tried to make drastic moves (optimize, replace with random) very low
> probability, and less
> drastic ones more often. The chance of doing nothing was approximately
> 50%.
>
> Hope this helps....
>
> Mark
>
>
> --
> Mark T. VandeWettering Telescope Information (and more)
> Email: <[EMAIL PROTECTED]> http://raytracer.org
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Continually Secure Password/Pin
Date: 9 Feb 2000 10:12:57 GMT
In article <87rbtr$33h$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>When creating and using a user/password account on the web why isn't
>the following method used:
>
>Client types in user name and password, clients computer sends server
>user name and the one millionth iterative one way hash of the password.
>Server creates user name and stores said hash.
>...
>I've searched to see if a similar system has been proposed before but
>couldn't find it. If it does, could someone give me pointers?
This is the S/Key system and it's been done in some other situations too.
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Question about DSA signature
Date: 9 Feb 2000 10:36:54 GMT
In article <[EMAIL PROTECTED]>,
Safuat Hamdy <[EMAIL PROTECTED]> wrote:
>Hi,
>
>Let p be a prime, q another prime such that q | (p - 1), let 1 < a < q, let
>gamma be an element of Zp* of order q and alpha = gamma^a.
>
>The signature step of DSA is, select a random k such that 1 < k < q and
>compute
>
> r = (gamma^k mod p) mod q
> s = k^(-1)(h(M) + a r) mod q
>
>the signature is(s, r).
>
>Q: Why is the r in the equation for s necessary, i.e. why can't one compute
>
> s = k^(-1)(h(M) + a) mod q
>
>(and adjust the verification step appropriately, of course). Would this be
>less secure?
>
I think Eve can forge the signature of any M' if you leave r out of the
equation. Here's how it would work. Suppose y is the public key:
y = gamma^a .
The adjusted verification step would be:
first check that r and s are in range.
compute ( gamma^[h(M) * s^-1 mod q] * y^[s^-1 mod q] ) mod p .
verify that the above result is equal to r .
To forge M' , simply do the following:
choose an arbitrary s (mod q) .
let r = ( gamma^[h(M') * s^-1 mod q] * y^[s^-1 mod q] ) mod p .
the pair (r, s) is a forged signature for M' .
You can verify yourself that it is not so easy to forge signatures
when you put r back in the equation.
Scott
------------------------------
From: Sisson <[EMAIL PROTECTED]>
Subject: Re: Anti-crack
Date: Wed, 09 Feb 2000 10:48:33 GMT
how did DVD encryption work? i thought that was uncrackable, and only
because Xing didn't encode their code was it able to be cracked.
>From Spendabuck
CJ wrote:
> Has anyone researched means of protecting
> programs from being cracked with encryption?
>
> I'm not an expert in either area, but what I understand
> of cracking is that ultimately you are looking for the
> machine instruction in the executable which compares
> password/serial number etc. to some given
> value.
>
> So I was thinking one could maybe encrypt this piece
> of the executable and decrypt on the fly when the application
> starts. You might be able to trace the decryption and try to
> spot the key used, but that would be more difficult (esp.
> as you wouldn't know what algorithm is used).
>
> I'm not sure one can prevent direct tracing of the executable
> code once it has been decrypted however. (I was thinking
> maybe having it in a DLL, but this is maybe traceable too.)
> Are there any better ways?
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Continually Secure Password/Pin
Date: Wed, 9 Feb 2000 21:44:21 +1100
'cos it's easier to sniff the keyboard, perhaps?
Lyal
[EMAIL PROTECTED] wrote in message <87rbtr$33h$[EMAIL PROTECTED]>...
>When creating and using a user/password account on the web why isn't
>the following method used:
>
>Client types in user name and password, clients computer sends server
>user name and the one millionth iterative one way hash of the password.
>Server creates user name and stores said hash.
>
>When logging on first time user sends user name and the 999,999th
>iterative hash of the password. Server authenticates by hashing this
>and comparing it to last stored hash. On acceptance it allows access to
>account and updates servers hashed password to the new 999,999th
>iteration.
>
>Next time user logs on he uses the 999,998th iteration and so on.
>
>No eavesdropper can imitate the user on future login sessions.
>
>Server uses little processing time as it only needs to hash once.
>
>A variation of the system can be used to authenticate non certified
>telephone conversations (secure or insecure). 2^24 iterated hashes of
>passwords and associated user id could be stored on a public server.
>This represents the authenticity of user at the time of posting on the
>server. To authenticate at a time after that, the person wishing to
>confirm their id publishes the (2^24-((time-servertime)seconds))th
>iterative hash. This can be confirmed by access to the public server.
>
>It also can be used too in credit card/cheque authorisations etc.
>
>I've searched to see if a similar system has been proposed before but
>couldn't find it. If it does, could someone give me pointers?
>
>Gary. At ArchRivals.F9.Co.UK
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: Gary <[EMAIL PROTECTED]>
Subject: Continually Secure Password/Pin
Date: Wed, 9 Feb 2000 06:01:59 -0500
When creating and using a user/password account on the web why isn't the
following method used:
Client types in user name and password, clients computer sends server user
name and the one millionth iterative one way hash of the password. Server
creates user name and stores said hash.
When logging on first time user sends user name and the 999,999th iterative
hash of the password. Server authenticates by hashing this and comparing it
to
last stored hash. On acceptance it allows access to account and updates
servers hashed password to the new 999,999th iteration.
Next time user logs on he uses the 999,998th iteration and so on.
No eavesdropper can imitate the user on future login sessions. Server uses
little processing time as it only needs to hash once.
A variation of the system can be used to authenticate non certified
telephone
conversations (secure or insecure). 2^24 iterated hashes of passwords and
associated user id could be stored on a public server. This represents the
authenticity of user at the time of posting on the server. To authenticate
at
a time after that, the person wishing to confirm their id publishes the
(2^24-((time-servertime)seconds))th iterative hash. This can be confirmed by
access to the public server.
It also can be used too in credit card/cheque authorisations etc.
I've searched to see if a similar system has been proposed before but
couldn't
find it. If it does, could someone give me pointers?
Gary. At ArchRivals.F9.Co.UK
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Anti-crack
Reply-To: [EMAIL PROTECTED]
Date: Wed, 09 Feb 2000 11:08:57 GMT
Sisson <[EMAIL PROTECTED]> wrote:
>how did DVD encryption work? i thought that was uncrackable, and only
>because Xing didn't encode their code was it able to be cracked.
www.opendvd.org
Xing made the "hack" take a few minutes longer than it would have
otherwise, but Xing were indeed in breach with their DVD-CCA license
anyway. If anyone ought to be sued, it should be Xing.
The DVD encryption is a joke, encredibly easy to break.
___/
_/
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
