Cryptography-Digest Digest #827, Volume #11 Sat, 20 May 00 22:13:00 EDT
Contents:
Re: Reasonably secure OTP passing (Guy Macon)
Re: FAQ out of date? (David A Molnar)
Re: ALIENS - RELIGION ("Leo Sgouros")
dining cryptographers in the disco - any code anywhere? (lose the crustacean to
email me)
Re: More on Pi and randomness ("r.e.s.")
Re: QUESTIONS About ALGOS !! ("Scott Fluhrer")
Re: Reasonably secure OTP passing (John Savard)
Re: what is the status finite automata base cryptosystems? (Chris Pollett)
Re: Jobs at Cloakware ("Trevor L. Jackson, III")
Re: ALIENS - RELIGION ("Sven Kalbitzer")
Re: dining cryptographers in the disco - any code anywhere? (David A Molnar)
Re: dining cryptographers in the disco - any code anywhere? (David A Molnar)
Re: dining cryptographers in the disco - any code anywhere? ("Leo Sgouros")
Re: On-line authentication protocol (Thomas Wu)
Re: QUESTIONS About ALGOS !! (tomstd)
Re: On-line authentication protocol (stanislav shalunov)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Reasonably secure OTP passing
Date: 20 May 2000 17:57:17 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
>This is why this method has, in general, been rejected out of hand.
>Why go to all the trouble of generating so many true random numbers?
>Why use up twice the bandwidth? It's so much simpler to just use a
>better conventional cryptosystem.
While I agree about the rest of what you say, the above (which I see
here in many other folks posts) seems to have a flaw in it's logic.
It assumes that everyone who uses cryptosystems has the following
properties:
[1] They know which available cryptosystems are better or worse.
[2] They currently do not use the best available cryptosystem.
It seems to me that, for most users, the following is more accurate:
[1] They have some clues know which available cryptosystems are better
or worse, but they really can't be sure.
[2] They currently use what they believe to be the best available
cryptosystem, but they are not sure that thay chose wisely.
In that case, they can't make tradeoffs between using a better
cryptosystem and improving the present scheme. Instead they must
make tradeoffs between thier valuation of various costs such as
bandwidth, time to learn the new system, etc., the estimated added
security of the change, the estimated resources of the attacker,
and the cost of having somneone crack the cryptosystem.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: FAQ out of date?
Date: 20 May 2000 21:34:08 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> I just briefly poked at the FAQ today, and saw mention of
> something called PES? Good god that is old!!!
If you look at the first section of the FAQ, you'll see a mysterious
note from the Crypt Cabal that indicates a revamp of the FAQ is
underway. I don't know anything more about it than that.
Back in September, I was considering a project aimed at assembling
volunteers to just go ahead and create an updated FAQ. The note from
the Crypt Cabal pre-empted that (strange timing - I wonder how that
worked out... :) . Looking back on how much time I have not had this
year, it is probably just as well.
Still, it has been months since that note, and no sign of progress.
I can understand this, though -- I need to write a next draft of
that FAQ on quantum computation...
Thanks,
-David
------------------------------
From: "Leo Sgouros" <[EMAIL PROTECTED]>
Crossposted-To: alt.alien.research,alt.alien.visitors
Subject: Re: ALIENS - RELIGION
Date: Sat, 20 May 2000 22:06:30 GMT
You speak the truth about this Bible Code book.
Can you tell him why?
Its about how you can fudge codes out of alphabets with missing letters when
you make the right blocks out of them, and draw the right goofy lines.
B:.B:.
"it is finished"
--
"and the four had one likeness,and their
appearance and their work was as it were
a wheel in the middle of a wheel"
www.mkshadows.net
"E. L." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
Jonny: You're referring to Ezekiel 2:12, 14-15. No one knows what he
claims he saw. I would simply say that as in modern times, people are
being picked up by tornadoes and being deposited a distance from where
they were picked up.
Regarding the book "The Bible Code," disabuse yourself from reading
ANYTHING into it. Do research here on the web and read all the prosaic
explanations for why there is no such thing as a bible code or, as you
say below, "...it gives you another perspective on the reasoning behind
the existence of the book (the Bible)." It doesn't do any of the sort.
The only perspective you get is the author's.
======================================================
Group: alt.alien.research Date: Sat, May 20, 2000, 2:28am (EDT+5) From:
[EMAIL PROTECTED] (Daryl Lloyd) Re: ALIENS - RELIGION
Read Ezekiel again, and this time read it with an open mind, not with
one enclosed by religious, mind-washing bullshit! Try telling me what he
claims he saw, and his being carried of to somewhere (I can't remember
right now, but believe me, I will find out again and tell you) were
natural phenomena and not intervention by a more advanced intelligence,
one with machines, not the ability to pick people up and carry them away
with thought alone.
And if you don't believe in extra-terrestrials, why do you feel the need
to come here and start a load of shit about something completely
irrelevant, i.e. MS versus Linux? What is the fucking point?
One last thing, try and find a book entitled 'The Bible Code'. I'm not
saying it's correct, all I'm saying is, it gives you another perspective
on the reasoning behind the existence of the book (the Bible).
If you want to start shit with me simply because I don't believe in your
'god', then go right ahead. But answer me two questions. Will you feel
better because you have done? Will it actually improve your life at all?
No matter what you do or say, I will not believe in any 'god' other than
the universe as a whole.
Boi-boi,
Love,
Jonny
xxxxx
------------------------------
From: davidh@postmaster lobster co uk (lose the crustacean to email me)
Subject: dining cryptographers in the disco - any code anywhere?
Date: Sat, 20 May 2000 23:40:18 +0000
Im looking to implement a DC-Net but all I can find are the various EuroCrypt98
papers.
I can find no actual code - or even Pseudo code. Im not 100% confident, so
I want to see someone elses. Can anyone help? even partial pseudo/code would be
helpful.
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
With Servers In California, Texas And Virginia - The Worlds Uncensored News Source
Webmasters New RevShare Program http://www.uncensored-news.com/revshare.html
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Date: Sat, 20 May 2000 15:47:21 -0700
"Clive Tooth" <[EMAIL PROTECTED]> wrote ...
[...]
| Some things are known about the decimal digits of pi
| in general. For example, for no positive integer n
| are the digits n thru 100*n all equal to zero.
Some such things are known in general, but I think that
that last sentence isn't one of them -- for if it's
true, then pi is not normal in base 10.
(Last I heard, normality of pi was an open question,
neither proved nor disproved. Have I missed something?)
--r.e.s.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: QUESTIONS About ALGOS !!
Date: Sat, 20 May 2000 16:43:44 -0700
Jerry Coffin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <8fu3it$osb$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> > I'm new in Encryption, and I've to implement an Encryption Algo
> > for an application.
> > But I have to make a choice between efficiency and speed !
> > Well I'd like to know if the DES / 3DES is a very fast algo ?
>
> No. Rather the opposite: DES is fairly slow and 3DES is about one
> third that speed.
Actually, before we make the pronouncements "DES is fairly slow and 3DES is
slower", we need to ask the question: how fast does the OP need them to be?
His definition of "very fast" may be drasticly different then our definition
of "very fast". If 3DES is fast enough for the OP (and none of the rest of
us know enough to say), then 3DES may be a fine choice.
>
> > I've been told that Blowfish algorithm was very fast and secure.
> > What do you think about it ?
I agree with Mr. Coffin: there is little reason to use Blowfish when Twofish
or the other AES finalists are available. You may want to avoid RC/6, for
intellectual property reasons as noted by others.
If they aren't fast enough, then you probably need to look at a stream
cipher (they tend to be a bit faster), faster hardware, or figuring out how
to make your application work with encryption that isn't quite as fast as
you wanted it...
--
poncho
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Reasonably secure OTP passing
Date: Sat, 20 May 2000 23:58:18 GMT
On 20 May 2000 17:57:17 EDT, [EMAIL PROTECTED] (Guy Macon) wrote,
in part:
>It assumes that everyone who uses cryptosystems has the following
>properties:
>[1] They know which available cryptosystems are better or worse.
>[2] They currently do not use the best available cryptosystem.
The basic assumption, in criticizing a proposed scheme as not helpful,
is that it isn't useful to someone who is knowledgeable. Those who
aren't sure what is a good cryptosystem are expected to follow the
advice of experts - which is good enough advice, if the alternative is
following the advice of newbies. Thus, saying that a proposal might or
might not help someone who _wasn't_ knowlegeable isn't really what is
meant.
But as for properties (1) and (2), they aren't as contradictory as
they seem. You can't use "the best available cryptosystem", in the
sense that one can always improve by using additional layers of
multiple encipherment. The general claim used to attack the proposal
(actually, my first improved form of it) is that it is no better than
using two layers of multiple encipherment - and it is at least
comparable, although that may not be strictly true that it is no
better.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: Chris Pollett <[EMAIL PROTECTED]>
Subject: Re: what is the status finite automata base cryptosystems?
Date: Sat, 20 May 2000 17:16:52 -0700
Tim Tyler wrote:
> Christopher Pollett <[EMAIL PROTECTED]> wrote:
>
> : Can anyone out there tell me what the current status of finite automata
> : based crypto systems?
>
> There are a couple which describe themselves as being "finite automata".
>
> There's the FAKPCS (Finite Automaton Public Key CryptoSystem).
> I have a bibliography for this at http://alife.co.uk/ca/publickey/biblio/
>
> It was covered in BS's AC. The early version of this was broken - but
> the replacement "Modified Finite Automata Public Key Cryptosystem" appears
> to be unscathed AFAIK.
>
> Then there's Howard Gutowitz's work at:
> http://www.santafe.edu/~hag/pat/pat.html This was also covered in BS's AC.
>
> This looks quite unusual to my eyes. I am unaware of it receiving much
> analytic attention.
>
> There's a significant sense in which all modern cryptosystems are "finite
> automata" - especially those designed for hardware implementation.
>
> Those that involve large prime numbers - or much in the way of addition or
> multiplication - don't often get described in this way, though.
> --
> __________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
Hi,
Thanks for the info.
Chris
------------------------------
Date: Sat, 20 May 2000 20:47:53 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Jobs at Cloakware
Discrete is spelled that way. It means [OED, 2nd ed, 1991] "Separate;
detached from others; individually distinct. Opposed to continuous".
Discreet means [same] "Showing discernment or judgment in the guidance of
one's own speech or action; judicious, prudent, circumspect, cautious; Often
esp. that can be silent when speech would be inconvenient"
Discreet messages often use ciphers based upon discrete mathematics.
Steve Hollasch wrote:
> Marlies Vincken wrote: << Knowledge of computational graph theory,
> complexity theory, number theory and discreet [sic] mathematics. >>
>
> David A Molnar wrote about "discreet mathematics" << This is a joke? >>
>
> Isn't it correct to say that cryptography is the study of discreet
> mathematics? =^)
Yes, but it is still a charming typo.
------------------------------
From: "Sven Kalbitzer" <[EMAIL PROTECTED]>
Crossposted-To: alt.alien.research,alt.alien.visitors
Subject: Re: ALIENS - RELIGION
Date: Sun, 21 May 2000 02:45:57 +0200
Leo Sgouros <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
G%DV4.8850$[EMAIL PROTECTED]
> You speak the truth about this Bible Code book.
> Can you tell him why?
> Its about how you can fudge codes out of alphabets with missing letters
when
> you make the right blocks out of them, and draw the right goofy lines.
>
> B:.B:.
>
>
> "it is finished"
>
>
> --
> "and the four had one likeness,and their
> appearance and their work was as it were
> a wheel in the middle of a wheel"
> www.mkshadows.net
> "E. L." <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> Jonny: You're referring to Ezekiel 2:12, 14-15. No one knows what he
> claims he saw. I would simply say that as in modern times, people are
> being picked up by tornadoes and being deposited a distance from where
> they were picked up.
>
> Regarding the book "The Bible Code," disabuse yourself from reading
> ANYTHING into it. Do research here on the web and read all the prosaic
> explanations for why there is no such thing as a bible code or, as you
> say below, "...it gives you another perspective on the reasoning behind
> the existence of the book (the Bible)." It doesn't do any of the sort.
> The only perspective you get is the author's.
> ------------------------------------------------------
> Group: alt.alien.research Date: Sat, May 20, 2000, 2:28am (EDT+5) From:
> [EMAIL PROTECTED] (Daryl Lloyd) Re: ALIENS - RELIGION
> Read Ezekiel again, and this time read it with an open mind, not with
> one enclosed by religious, mind-washing bullshit! Try telling me what he
> claims he saw, and his being carried of to somewhere (I can't remember
> right now, but believe me, I will find out again and tell you) were
> natural phenomena and not intervention by a more advanced intelligence,
> one with machines, not the ability to pick people up and carry them away
> with thought alone.
> And if you don't believe in extra-terrestrials, why do you feel the need
> to come here and start a load of shit about something completely
> irrelevant, i.e. MS versus Linux? What is the fucking point?
> One last thing, try and find a book entitled 'The Bible Code'. I'm not
> saying it's correct, all I'm saying is, it gives you another perspective
> on the reasoning behind the existence of the book (the Bible).
> If you want to start shit with me simply because I don't believe in your
> 'god', then go right ahead. But answer me two questions. Will you feel
> better because you have done? Will it actually improve your life at all?
> No matter what you do or say, I will not believe in any 'god' other than
> the universe as a whole.
> Boi-boi,
> Love,
> Jonny
> xxxxx
>
> That was well put. - Sven
>
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: dining cryptographers in the disco - any code anywhere?
Date: 21 May 2000 00:45:41 GMT
lose the crustacean to email me <davidh@postmaster lobster co uk> wrote:
> Im looking to implement a DC-Net but all I can find are the various EuroCrypt98
>papers.
Eurocrypt 98 -- those two are on mix-nets, aren't they (by
Jakobsson and Abe)? Which do you actually want -- a mixnet or a DC-net?
There's code which implements various kinds of mix-nets. Sadly I don't
know of any code which implements mix-nets whose correctness is guaranteed
by zero-knowledge proofs in the way that Jakobsson's and Abe's designs
are. Note also, by the way, that Desmedt and Kurosawa(?) have a paper
in Eurocrypt '00 which claims to break Jakobsson's practical mix.
Check mixmaster.anonymizer.com for a start. I don't know of any
code which implements a DC-net, although I have this hazy recollection
of some cypherpunks trying to do it over IRC a long time ago.
> I can find no actual code - or even Pseudo code. Im not 100% confident, so
> I want to see someone elses. Can anyone help? even partial pseudo/code would be
>helpful.
Have you looked at the "Dining Cryptographers in the Disco" paper?
They have a summation of the protocol which is almost like pseudocode.
You might try looking at David Martin's thesis or contacting him directly.
He describes a "superposed sending" protocol and gives an implementation
report in his phd thesis, found here :
http://www.cs.du.edu/~dm/anon.html
The protocol sounds a bit similar to a DC-net, but I haven't read
over it in depth yet.
Thanks,
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: dining cryptographers in the disco - any code anywhere?
Date: 21 May 2000 00:46:23 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
>> I can find no actual code - or even Pseudo code. Im not 100% confident, so
>> I want to see someone elses. Can anyone help? even partial pseudo/code would be
>helpful.
> Have you looked at the "Dining Cryptographers in the Disco" paper?
> They have a summation of the protocol which is almost like pseudocode.
duhh. sorry. I'll read the subject line in full next time. :-(
------------------------------
From: "Leo Sgouros" <[EMAIL PROTECTED]>
Subject: Re: dining cryptographers in the disco - any code anywhere?
Date: Sun, 21 May 2000 01:10:59 GMT
Its an awesome band.
"problem child"
RIP Bon Scott :-)
--
"and the four had one likeness,and their
appearance and their work was as it were
a wheel in the middle of a wheel"
www.mkshadows.net
"David A Molnar" <[EMAIL PROTECTED]> wrote in message
news:8g7bkv$hch$[EMAIL PROTECTED]...
> David A Molnar <[EMAIL PROTECTED]> wrote:
> >> I can find no actual code - or even Pseudo code. Im not 100% confident,
so
> >> I want to see someone elses. Can anyone help? even partial pseudo/code
would be helpful.
>
> > Have you looked at the "Dining Cryptographers in the Disco" paper?
> > They have a summation of the protocol which is almost like pseudocode.
>
> duhh. sorry. I'll read the subject line in full next time. :-(
>
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: On-line authentication protocol
Date: 20 May 2000 18:10:29 -0700
Richard Heathfield <[EMAIL PROTECTED]> writes:
> I would welcome your views on the following authentication protocol,
> which I and a work colleague designed, and which incorporates at least
> one idea garnered from sci.crypt :-) - I hope to use this protocol if it
> stands up to scrutiny; my interest is not just theoretical.
>
> Comments?
>
>
>
> Requirement:
>
> Client wishes to talk to server.
> Client must know that he's talking to the *right* server, not an
> impostor.
> Server must be assured of client's identity.
>
> +++
>
> Threat model:
>
> Spotty but clever teenager with an attitude and a packet sniffer.
You're assuming that the client and server already have a safe copy of
each other's public key, and that the corresponding private keys have
high entropy. I say this because if this assumption is not met, your
protocol can be trivially broken - MITM attacks and all that.
If this assumption is met, your proposal appears to be more computationally
expensive than a simple mutually-signed DH exchange (g^x and g^y are
signed by the corresponding side's private key), while offering no
greater security in exchange for the greater complexity. For examples,
look at IPSEC/IKE/SSH2 etc.
If you allow for low-entropy private keys, e.g. passwords, then you'd
want to use a strong password method like SRP or SPEKE.
http://srp.stanford.edu/srp/
http://www.integritysciences.com/
Let me know if you want elaboration on any of the above points.
>
> +++
>
> Legend: S = Server C = Client pK = private Key PK = Public Key DHK =
> Diffie-Hellman Key
>
> Diffie-Hellman: N = (Y^X) % P (SN = N generated by server, CN = N
> generated by client)
>
> Thus, SPK(T) means that T has been encrypted using the server's public
> key.
>
> +++
>
> Protocol overview:
>
> Client Server
>
> 1. -> "Hello" (in clear) ->
> 2. <- Y, P, SN <-
> 3. -> CN, DHK("Dave") ->
> 4. <- DHK(CPK(SpK(Random session ID 1))) <-
> 5. -> DHK(SPK(CpK(Session ID 1,
> Session ID 2))) ->
> 6. <- DHK(CPK(SpK(Session ID 2,
> New Y, P, SN))) <-
> 7. -> DHK(SPK(CpK(N, Session IDs,
> First productive message))) ->
> 8. <- DHK2(Session IDs,
> First productive response) <-
> 9. -> DHK2(Session IDs, second message) ->
>
> +++
>
> Protocol detail:
>
> 1. -> "Hello" (in clear) ->
>
> Client informs server that he wants to establish a connection. No
> security or authentication at this stage.
>
>
> 2. <- Y, P, SN <-
>
> Server picks an X, and responds with the three elements the client needs
> for Diffie-Hellman. (Server pre-calculates its own N, which it can do
> independently.)
>
> 3. -> CN, DHK("Dave") ->
>
> Client picks an X, works out the Diffie-Hellman key, encrypts his
> identification, and sends it to the server, together with unencrypted N.
>
> 4. <- DHK(CPK(SpK(Random session ID 1))) <-
>
> Now the server wishes to authenticate that this really is Dave, not an
> impostor or a replay attack. Server picks a random session ID. (Yes, I
> know random number generation is an issue for heavy NSA-type threat
> models...), encrypts with its private key, as a digital signature, then
> encrypts with "Dave"'s public key, then encrypts with the session key
> already established. Note: If Dave is not known to the server, it will
> pick a completely random public key for the encryption, to avoid leaking
> information about user names unnecessarily.
>
> 5. -> DHK(SPK(CpK(Session ID 1,
> Session ID 2))) ->
>
> Client retrieves session ID by applying DHK, CpK, and SPK. Client now
> re-encrypts Session ID 1 using CpK, SPK, and finally DHK. If the client
> does this successfully, the server can be reasonably assured that he's
> talking to Dave.
>
> The client also includes its own randomly-generated session ID, so that
> the client can authenticate the server.
>
> 6. <- DHK(CPK(SpK(Session ID 2,
> New Y, P, SN))) <-
>
> Server works out the client's session ID, and sends it back to the
> client, together with a new Y, P and SN for a new Diffie-Hellman key.
> Client can now authenticate the server.
>
> 7. -> DHK(SPK(CpK(N, Session IDs,
> First productive message))) ->
>
> The client works out the key, sends back its N, both session IDs, and
> the first payload message.
>
> 8. <- DHK2(Session IDs,
> First productive response) <-
>
> From now on, the private/public key encryption can be dropped, provided
> both the session IDs are included in every message for the duration of
> that session.
>
> 9. -> DHK2(Session IDs, second message) ->
>
> Identification is now authenticated in both directions.
>
> +++
>
> Analysis:
>
> Well, I already found a bug (client wasn't authenticating server) which
> I've fixed.
>
> I know the random number generation is a theoretical weakness, and I
> know the encryption algorithm used for the outer Diffie-Hellman wrapper
> is an unknown factor - let's assume for the moment that it's a good
> strong algorithm.
>
> I would welcome comments from the clueful on the security of the actual
> protocol.
>
>
> --
>
> Richard Heathfield
>
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
>
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> 37 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (60
> to go)
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
Subject: Re: QUESTIONS About ALGOS !!
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 20 May 2000 18:35:19 -0700
In article <8g78oq$fm2$[EMAIL PROTECTED]>, "Scott
Fluhrer" <[EMAIL PROTECTED]> wrote:
>
>Jerry Coffin <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> In article <8fu3it$osb$[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
>> says...
>>
>> > I'm new in Encryption, and I've to implement an Encryption
Algo
>> > for an application.
>> > But I have to make a choice between efficiency and speed !
>> > Well I'd like to know if the DES / 3DES is a very fast
algo ?
>>
>> No. Rather the opposite: DES is fairly slow and 3DES is
about one
>> third that speed.
>
>Actually, before we make the pronouncements "DES is fairly slow
and 3DES is
>slower", we need to ask the question: how fast does the OP need
them to be?
>His definition of "very fast" may be drasticly different then
our definition
>of "very fast". If 3DES is fast enough for the OP (and none of
the rest of
>us know enough to say), then 3DES may be a fine choice.
3des is not a bad choice, just not a good one for many tasks.
It's cumbersome and slow.
>
>> > I've been told that Blowfish algorithm was very fast and
secure.
>> > What do you think about it ?
>I agree with Mr. Coffin: there is little reason to use Blowfish
when Twofish
>or the other AES finalists are available. You may want to
avoid RC/6, for
>intellectual property reasons as noted by others.
>
>If they aren't fast enough, then you probably need to look at a
stream
>cipher (they tend to be a bit faster), faster hardware, or
figuring out how
>to make your application work with encryption that isn't quite
as fast as
>you wanted it...
I disagree, just as an example I have RC5 code with 12 rounsd
[1] that runs at 135 cycles/block [2]. If this is not fast
enough then tough...
[1] at 12 rounds the best differential attack requires 2^53
pairs.
[2] http://www.tomstdenis.com/rc5asm.zip (educational use only)
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: On-line authentication protocol
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 02:08:00 GMT
The protocol seems very complicated. Design goals aren't spelled out.
Do you assume that the server can share an individual secret
(password, key, any piece of data) with each client?
If so,
Do you assume that server is allowed to store these secrets in
cleartext?
Do you assume that this secret will be remembered by a human?
Do you assume that a client can store its secret in cleartext?
Do you assume that every comminucating party has uses a PK
cryptosystem, and every party has a key pair?
If so,
Do you assume that each client knows server's public key?
Do you assume that server knows each client's public key?
What are your efficiency requirements?
Can an attacker modify network packets?
Is there a single server or a large number of servers, with the same
trust scheme?
How long is a typical session, in time and in bytes?
Do you need to be resistant to dictionary attacks performed by
(a) observer on the network?
(b) fake server?
Is it OK if a fake server learns some stuff from the client, but
client immediately learns that the server was a fake and changes its
password/key pair out of band?
In case of server compromise (root taken over), what is it OK if
earlier sessions are decrypted?
Etc.
You're not saying what your requirements are, so it's impossible to
tell you whether your protocol matches them.
--
stanislav shalunov | Speaking only for myself.
------------------------------
** 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
******************************
