Cryptography-Digest Digest #432, Volume #11 Mon, 27 Mar 00 22:13:01 EST
Contents:
Re: Cipher Contest ("Adam Durana")
Re: NIST publishes AES3 papers (Uri Blumenthal)
Re: NIST publishes AES3 papers (Uri Blumenthal)
Re: Does anybody know of a secure FTP server? (Abid Farooqui)
Re: Mixing N bits into N bits (stanislav shalunov)
diversity in key management ([EMAIL PROTECTED])
Re: Cipher Contest ("Adam Durana")
Re: one-way hash functions with 256-bit output (stanislav shalunov)
Re: Mixing N bits into N bits (Johnny Bravo)
Re: Checking for a correct key ("Joseph Ashwood")
Re: Mixing N bits into N bits (Dan Day)
Re: one-way hash functions with 256-bit output ("Rich Ankney")
Re: one-way hash functions with 256-bit output (David A. Wagner)
Re: Method for time-altering keys ("RecilS")
Re: NIST publishes AES3 papers (David A. Wagner)
Re: polynomial fitting to noisey data (Phil Henshaw)
Re: polynomial fitting to noisey data ("Leo Sgouros")
----------------------------------------------------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Mon, 27 Mar 2000 18:52:17 -0500
Yes the contest has started, I posted an announcement a few days ago, maybe
someone from the shadows quickly removed it from all the news servers! I
have been meaning to update the web site with the new requirements, but
basically they are that an entry be a block cipher and have
reasonable/justifiable resource usage. So work on your paper now if you
can't find my previous post about the start of the contest, I believe the
subject was "Start of Cipher Contest", I will update the web site very soon.
One more thing if anyone has sent an entry into [EMAIL PROTECTED] if
you could please send it again it would save me a lot of time. I believe
all mail coming to the address above has been lost, well not lost but sent
to the wrong user, if you could send your entries again it would save me the
time of tracking down the originals.
- Adam
<[EMAIL PROTECTED]> wrote in message
news:8bohs3$rif$[EMAIL PROTECTED]...
> Adam,
>
> What is the status of the contest? Has it started yet? If not, when
> does it start.
>
> Anyone interested in this contest should check out the latest papers on
> AES at the NIST site. The cryptanalysis papers are all suprisingly easy
> to understand.
>
> --Matthew
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Date: Mon, 27 Mar 2000 19:37:47 -0500
Reply-To: [EMAIL PROTECTED]
Joseph Ashwood wrote:
> With as much respect as I have for both of you, I still
> disagree. To me triple-DES appears as little more than DES
> with 3x the rounds.
Actually, 3DES is a little *less* than DES with 3x rounds!
> While that clearly gives a great image
> of it's security, it seems to me that it would have been
> just as secure to create an expanded DES with 3x the rounds,
> which would give a smaller key.
An expanded DES with 3x rounds can be *more* secure
(depending on how the round subkeys are computed).
With the right key expansion techniques one can
easily have variable key length, satisfying everybody. (:-)
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Date: Mon, 27 Mar 2000 19:48:17 -0500
Reply-To: [EMAIL PROTECTED]
"David A. Wagner" wrote:
> > ........it would have been just as secure to create an
> > expanded DES with 3x the rounds........
>
> But then you must choose a new key schedule for this
> DES-variant,
True.
> ...... and that would be dangerous. It would
> "void the security warranty" -- i.e., invalidate the
> decades of analysis on DES -- and we'd have to start
> over from scratch with the analysis.
Not necessarily - because plenty of analysis has
been done on DES with independent subkeys. So
one can utilize the results.
And just as we can't prove the exact strength
of DES (we only know how much time has been
spent developing currently-known attacks,
and what's the best result these
attacks achieved SO FAR), we
can't prove the strength of
the proposed variant.
And just as we can - with lot of good reasons - believe
that DES has certain strength, we can establish direct
relations between the properties of DES and of variant,
providing - with good reasons - the probable strength
of the modified algorithm.
[P.S. I feel passionate about DES variants. :-]
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: Abid Farooqui <[EMAIL PROTECTED]>
Subject: Re: Does anybody know of a secure FTP server?
Date: Tue, 28 Mar 2000 00:48:41 GMT
Nuno,
Your English is actually quite decent, you just keep using "his" when it should be
"is" :) ... but who cares ... thanks for the reply my friend and even though I
don't know Portugese I do speak and write 4 languages, mostly Asian in origin
including Urdu, Sindhi and Persian. The fourth one of course is English. Could not
live in Florida without knowing English or may be Spanish would work as well ...
hehehe.
Now to the serious stuff ... you mentioned transferring files over a SSL ftp server
but you rightly mentioned that ftp clients don't support ftps. Is there even one
ftp client that has good support of SSL. I have the ability to make all my users
use whichever ftp client I want them to use. So even if there is one ftp client out
there that will work with SSL that can really solve my problem.
Secondly, you mentioned that the best solution is to use Https to transfer files.
The problem there is that I want my users to be able to upload files to the
webserver as well as download them from the webserver. I would in this case have to
write a trusted Java applet that can access local machine's I/O and thus give them
the ability to select the files that they want to upload to the webserver securely.
Some pain involved there but I can deal with that. I am requiring that all my users
have a personal certificate and that this certificate be presented to the webserver
for connection authentication. The webserver checks the attributes of this
certificate with attributes listed on a DB attached to the webserver and only if
they match, does it allow you to make a Https connection. Now a question for you,
or for anyone else here
Where can I find these SSL accelerator cards, I am assuming that they are similar
to crypto chips available for encryption/decryption. What platforms are these cards
available for? and which webservers do these cards support? Are there some websites
I can look at to get some info about these accelerator cards?
If you can answer these questions, you have saved me a whole bunch of time and if I
ever come to Portugal, I'll personally come and thank you.
Best Regards.
Abid Farooqui
Nuno Jaime Cardoso wrote:
> Abid Farooqui wrote:
>
> > Ok that is helpful to know but do you know of any ftp servers that either
> > have a module to do ftps or ftps is built in. Can they be set with different
> > options like ssl on Apache using httpd.conf file etc.
> > Secondly, do any of you know of a SSL module for apache or any other
> > webserver or ftp server that does encryption/decryption in hardware like on a
> > crypto chip so that precious CPU time and cycles are spared from this task. I
> > am trying to set up a system where I will be sending large files (GB of data)
> > over SSL to and from a SSL enabled webserver/ftp server.
> > Thanks
> > Abid Farooqui
>
> Some time ago I made a proposal to a customer that required a FTP server over
> SSL that integrates with Netscape Products and, I remember that I found him one
> but, he had several problems because the FTP clients aren't ready to support
> SSL. Remember that not only the server, but also the client, has to support the
> protocol. (Quite obvious but, people usualy forget that). The thing his that
> there are very few FTP clients that use SSL.
>
> The best way his realy to have the files transfered by Https, using an Web
> Server and, if you don't have money for a powerfull machine, I recomendthat you
> buy an SSL acelerator card, they realy work and they realy incresase
> performance.
>
> Sorry for any eventual mistakes i gave with my English but, I believe that my
> English his a lot better than your Portuguese :)))))
>
> Bye
>
> //Jaime Cardoso
------------------------------
Subject: Re: Mixing N bits into N bits
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Tue, 28 Mar 2000 00:49:09 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> What properties must F satisfy in order that your function based
> on the Feistel construction is 1-1? A F that maps everything to 0
> certainly wouldn't do.
As Tim Tyler has pointed out, for F mapping anything to a string of
zeros, a single round would simply swap the halves. (And for even
number of rounds you'd get the identity function.)
It's easy to prove that Feistel network always gives an invertible
function. The key fact is that A XOR F(something) XOR F(something) = A,
so we can simply present the reverse function.
See implementation of any common Feistel network as an example (DES,
Blowfish, etc.; most block ciphers in common use are Feistel
networks).
------------------------------
From: [EMAIL PROTECTED]
Subject: diversity in key management
Date: Tue, 28 Mar 2000 00:43:56 GMT
Hi, and thank you for the information before concerning key management
questions. However, my question now is at a higher level. What is the problem
with diverse email key management systems in the first place? Is it user
frustration, being unable to send encrypted messages to ANY user because of
different key maintanence functions between different email platforms? Is it
increased email encryption development costs because vendors don't have
concrete standards which guide encryption function implementations? Is it a
nuisance to privacy advocates and others because missing standards are
preventing wide email encryption usage, which is problematic in an
"information-based" economy? I don't know the market space enough yet, but it
is possible that the diverse key mgmt. implementations are serving their
market niches? For example, in corporate environments, a centralized hiearchy
of Certificate Authorities (rooted at a Verisign-type of CA) may be
appropriate for a large structured environment. In smaller groups, where
privacy might be less an issue, a PGP-typeof mutual authentication may be
more appropriate. Finally, who says that over time, some standard will not
develop? Perhaps S/MIME (or another standard) will ultimately be installed on
all email platforms in the US?
Any comments?
Thank you,
Stanley Trepetin
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Mon, 27 Mar 2000 18:52:17 -0500
Yes the contest has started, I posted an announcement a few days ago, maybe
someone from the shadows quickly removed it from all the news servers! I
have been meaning to update the web site with the new requirements, but
basically they are that an entry be a block cipher and have
reasonable/justifiable resource usage. So work on your paper now if you
can't find my previous post about the start of the contest, I believe the
subject was "Start of Cipher Contest", I will update the web site very soon.
One more thing if anyone has sent an entry into [EMAIL PROTECTED] if
you could please send it again it would save me a lot of time. I believe
all mail coming to the address above has been lost, well not lost but sent
to the wrong user, if you could send your entries again it would save me the
time of tracking down the originals.
- Adam
<[EMAIL PROTECTED]> wrote in message
news:8bohs3$rif$[EMAIL PROTECTED]...
> Adam,
>
> What is the status of the contest? Has it started yet? If not, when
> does it start.
>
> Anyone interested in this contest should check out the latest papers on
> AES at the NIST site. The cryptanalysis papers are all suprisingly easy
> to understand.
>
> --Matthew
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
Subject: Re: one-way hash functions with 256-bit output
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Tue, 28 Mar 2000 00:54:35 GMT
Runu Knips <[EMAIL PROTECTED]> writes:
> Well I would like to know that too. I've already thought of simply
> mixing the outputs of SHA-1 and RIPE MD160 so the result is 256 bit,
> but thats of course not a standard algorithm with a paper etc.
Right now, a lot of people simply concatenate MD5 and SHA1 outputs.
That doesn't seem to be a good solution, because these two functions
contain conceptual similarities in design.
Having a standard primitive would be helpful for a lot of things.
E.g., consider a global information retrieval protocol that accepts a
one-way hash as the "name" of the file to be sent back. Caching would
become very simple.
(Something like NNTP could be used for notifications about new
existing available files, but the files themselves wouldn't be
transferred; each entry point into the system would remember where in
the graph is the nearest node that already has this file.)
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Mixing N bits into N bits
Date: Mon, 27 Mar 2000 19:54:41 -0500
On 26 Mar 2000 19:44:06 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>I am using the number of seconds since Jan 1, 2000 (32 bit integer)
>in a ciphersaber variant that I am doing just to learn more.
>Needless to say, the bits on the LSB end change a lot and the bits
>on the MSB end don't.
If you are using this as a IV for ciphersabre, it won't matter, as long
as each message uses a different IV you are fine. Even a simple counter
from 0 would be ok. For two way communication, you should use a different
passphrase for each originator to make sure that all messages have
different IVs, or for two people with shared passphrases make sure one
person uses even IVs and the other uses odd ones to prevent messages
encrypted at the same time from different people have different IVs.
> I would like to convert the variable into a
>32 bit variable where each bit is equally likely to flip as time
>increments, yet I want to keep the property that I am 100% certain
>that the variable will never repeat in this century.
That is a pretty stiff design requirement, there is no security risk in
your original scheme unless both parties encrypt a message in the same
second. The chances of a collision in an 80 bit IV picked at random are
damn low already, if it really concerns you that much, you can assign
blocks of IVs to each user and let each user just increment the count
through the assigned IVs. With 80 bits you aren't likely to run out.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Checking for a correct key
Date: Mon, 27 Mar 2000 17:18:32 -0000
> What if I encrypted only very small files (1-100 byte for
example)?
> Wouldn't the hash make an attack much easier?
It shouldn't, and if you use a cryptographically strong hash
function (SHA-1 is a good example), it will be extremely
difficult, at least as difficult as breaking the encryption.
> My files will probably
> be somewhat bigger, but would it be better to store some
junk data in
> the files if they get too short?
The security implications are at best debatable. By
supplying more ciphertext you could open yourself up to an
attack (not likely unless you go to some VERY large file
sizes, as in 2^60+ bytes for even the most minimal secure
algorithm). Alternately you are decreasing knowledge of the
length of the file.
Joe
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Mixing N bits into N bits
Date: Tue, 28 Mar 2000 01:35:30 GMT
On 26 Mar 2000 19:44:06 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>I would like to convert the variable into a
>32 bit variable where each bit is equally likely to flip as time
>increments, yet I want to keep the property that I am 100% certain
>that the variable will never repeat in this century.
Before you solicit questions on how to achieve the two criteria
you mention above, perhaps you should ask whether your usage
of the 32-bit number actually requires both, or even either,
criteria.
If it's not giving away any Big Secrets, what are you going to
use the 32-bit number for? Then we could help you decide what
properties it truly needs to exhibit.
The main reason I'm asking is because I'm hard pressed to think
of any CipherSaber application that would require a number that
is "100% certain" not to "repeat in this century".
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: "Rich Ankney" <[EMAIL PROTECTED]>
Subject: Re: one-way hash functions with 256-bit output
Date: Mon, 27 Mar 2000 20:52:34 -0500
You might want to wait for SHA-2, which will supposedly have 256-
and 512-bit outputs (along with 384-bits truncated from 512). Supposedly
available late summer from NIST.
Regards,
Rich
stanislav shalunov wrote in message
<[EMAIL PROTECTED]>...
>Runu Knips <[EMAIL PROTECTED]> writes:
>
>> Well I would like to know that too. I've already thought of simply
>> mixing the outputs of SHA-1 and RIPE MD160 so the result is 256 bit,
>> but thats of course not a standard algorithm with a paper etc.
>
>Right now, a lot of people simply concatenate MD5 and SHA1 outputs.
>That doesn't seem to be a good solution, because these two functions
>contain conceptual similarities in design.
>
>Having a standard primitive would be helpful for a lot of things.
>E.g., consider a global information retrieval protocol that accepts a
>one-way hash as the "name" of the file to be sent back. Caching would
>become very simple.
>
>(Something like NNTP could be used for notifications about new
>existing available files, but the files themselves wouldn't be
>transferred; each entry point into the system would remember where in
>the graph is the nearest node that already has this file.)
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: one-way hash functions with 256-bit output
Date: 27 Mar 2000 17:08:11 -0800
In article <[EMAIL PROTECTED]>,
stanislav shalunov <[EMAIL PROTECTED]> wrote:
> Right now, a lot of people simply concatenate MD5 and SHA1 outputs.
> That doesn't seem to be a good solution, because these two functions
> contain conceptual similarities in design.
And, with respect to secrecy, the security you get is only as
good as the weaker of the two components, which is not ideal.
(If either MD5 or SHA1 leak a bit of information on the input,
then their concatenation will, too.)
------------------------------
From: "RecilS" <[EMAIL PROTECTED]>
Subject: Re: Method for time-altering keys
Date: Mon, 27 Mar 2000 21:12:39 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
I too, think that a random value would be better but here's my
reasoning...
a) A random value would obviously have to be transmitted and I'm more
worried about interception
b) I want cracks attempted in the future (without knowledge of the
transmission time) to be almost impossible
c) I will also be including the processor ID, IP address and other
user-specific variables into my scheme under the same methods. Not
to make it harder to crack, but more time and effort consuming.
- - Doug
Lyalc wrote in message ...
>A critical benefit arises from the suggestion to add time bits to
>the user's pass phrase.
>This adds a "specific use" element to the use of the password (or
>any other shared secret), increasing the ease of replay detection.
>And, it's used in several environments today - and in the future.
>
>Lyal
>
>
>Adam Durana wrote in message ...
>>
>>I think I follow even though your explanation could be better. But
>>what is the point of doing this? Letting the time affect the key
>>just seems like a weakness, i.e. if someone knows what time the key
>>was made they know some
>of
>>the key bits, or the ordering of the bits depending on what your
>>method does. I still can't think of a case where you would want a
>>key to be affected by the time it was created, unless you can
>>derive that time from the key without giving away the key. Keys
>>that expire are interesting but this method does not do that. Also
>>why even bother reordering the bits? Just attach the output of
>>time(0) to the end of the passphrase the user provided.
>>
>>And I do suggest you read "the statistical report analysis for time
>>sensitive PF417 gJq10 data proccessing routine".
>>
>>- Adam
>>
>>
>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOOAVFRJETAFqh0RgEQLq/QCgpxYsUhQNqudUhMAiqLBFb3ZGh3kAn0Rc
SNOGpRuYlNvPy4esIOsTL5B9
=fr6Y
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: NIST publishes AES3 papers
Date: 27 Mar 2000 17:41:50 -0800
In article <[EMAIL PROTECTED]>,
Uri Blumenthal <[EMAIL PROTECTED]> wrote:
> Not necessarily - because plenty of analysis has
> been done on DES with independent subkeys. So
> one can utilize the results.
Yup. If we can convince ourself that the new key schedule gives us
something close enough to independent subkeys, then I agree that we can
reuse existing analysis on DES.
------------------------------
From: Phil Henshaw <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.physics,alt.religion.kibology
Subject: Re: polynomial fitting to noisey data
Date: Mon, 27 Mar 2000 21:34:12 -0500
Reply-To: [EMAIL PROTECTED]
Leo Sgouros wrote:
>
> "Phil Henshaw" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> >
> > Bryan Reed wrote:
> > > In article <8aqhun$5jv$[EMAIL PROTECTED]>,
> > > Richard Herring <[EMAIL PROTECTED]> wrote:
> > > >In article <[EMAIL PROTECTED]>, Colin E.
> ([EMAIL PROTECTED]) wrote:
> > > >> Does anyone know of any references to similar work? or know of any
> > > >> scheme that enables one to accurately determine the curvature of a
> > > >> specimen from data with experimental noise? or does anyone know how to
> > > >> reduce the edge-effect mentioned?
> > > >
> > > >Splines?
> > > Try Bevington's "Data Reduction and Error Analysis for the Physical
> > > Sciences." There are algorithms for polynomial fits.
> > A better approach would be to try curvature scale space techniques,
> > basically gaussian smoothing, to develop the shape organically.
... clip
> be a way to track memes backwards?
> one should be able to do some neat decrypting of previous output by tracking
> the memes
curious... some meme made you say it I suppose :))
--
Phil Henshaw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
167 W 87th St NY NY 10024
tel: 212-579-2914
explorations: http://idt.net/~ph
------------------------------
From: "Leo Sgouros" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.physics,alt.religion.kibology
Subject: Re: polynomial fitting to noisey data
Date: Tue, 28 Mar 2000 02:52:41 GMT
please see
"Cairo global psychotronic broadcast"
/display intent ....here --------->.
"Phil Henshaw" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Leo Sgouros wrote:
> >
> > "Phil Henshaw" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > >
> > >
> > > Bryan Reed wrote:
> > > > In article <8aqhun$5jv$[EMAIL PROTECTED]>,
> > > > Richard Herring <[EMAIL PROTECTED]> wrote:
> > > > >In article <[EMAIL PROTECTED]>, Colin E.
> > ([EMAIL PROTECTED]) wrote:
> > > > >> Does anyone know of any references to similar work? or know of
any
> > > > >> scheme that enables one to accurately determine the curvature of
a
> > > > >> specimen from data with experimental noise? or does anyone know
how to
> > > > >> reduce the edge-effect mentioned?
> > > > >
> > > > >Splines?
> > > > Try Bevington's "Data Reduction and Error Analysis for the Physical
> > > > Sciences." There are algorithms for polynomial fits.
> > > A better approach would be to try curvature scale space techniques,
> > > basically gaussian smoothing, to develop the shape organically.
> ... clip
> > be a way to track memes backwards?
> > one should be able to do some neat decrypting of previous output by
tracking
> > the memes
>
> curious... some meme made you say it I suppose :))
>
> --
> Phil Henshaw
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 167 W 87th St NY NY 10024
> tel: 212-579-2914
> explorations: http://idt.net/~ph
------------------------------
** 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
******************************
