Cryptography-Digest Digest #900, Volume #13 Wed, 14 Mar 01 22:13:00 EST
Contents:
Re: Digital enveloppe (William Hugh Murray)
Re: Digital enveloppe (br)
Re: Noninvertible encryption (SCOTT19U.ZIP_GUY)
Re: Digital enveloppe (Darren New)
Re: NTRU - any opinions (Benjamin Goldberg)
Re: Dynamic Transposition Revisited Again (long) ("Joseph Ashwood")
Re: qrpff-New DVD decryption code (Benjamin Goldberg)
Re: Digital enveloppe ("Tom St Denis")
Re: OverWrite: best wipe software? (Anthony Stephen Szopa)
Porta algorithm (Sean Dwyer)
Re: Digital enveloppe (Tony L. Svanstrom)
Re: Instruction based encryption (Benjamin Goldberg)
Re: Porta algorithm (Jim Gillogly)
Re: Instruction based encryption ("Michael Brown")
Re: The Foolish Dozen or so in This News Group ("Joseph Ashwood")
Re: AES and DES ("Joseph Ashwood")
----------------------------------------------------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Digital enveloppe
Date: Thu, 15 Mar 2001 00:09:48 GMT
Tom St Denis wrote:
> "br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > I have no confidence on PGP or any other software.
> > Once, my idea of digital enveloppe achieved, I will disclose to everyone
> > the source. Everyone could compile it and use it.
>
> What does your d.e idea do anyways? Is it a public key algorithm,
> symmetric? etc...
>
> > If you feel safe using PGP, great.
>
> I don't use PGP either...
>
> > Digital enveloppe is secure and easy to achieve.
>
> I'll bet.
>
> > I'm just trying to find better formula than that I had yet realized.
> > Thanks for your comment.
>
> Righto.
>
> Tom
Please do not feed the trolls.
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Re: Digital enveloppe
Date: Wed, 14 Mar 2001 19:11:57 -0400
It's a way to send a message that only the authorized recipient could
read.
Without password or Pin.
The recipient has just to use the same software.
And to communicate only once with the sender.
Sample : If I send you a simple message the first time and you answer me
using the same software. You don't need any password to read my message.
And vice versa.
No one can read the message. Only your computer. You can't read the
message in other computers.
I hope it was clear.
Tom St Denis wrote:
>
> "br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > I have no confidence on PGP or any other software.
> > Once, my idea of digital enveloppe achieved, I will disclose to everyone
> > the source. Everyone could compile it and use it.
>
> What does your d.e idea do anyways? Is it a public key algorithm,
> symmetric? etc...
>
> > If you feel safe using PGP, great.
>
> I don't use PGP either...
>
> > Digital enveloppe is secure and easy to achieve.
>
> I'll bet.
>
> > I'm just trying to find better formula than that I had yet realized.
> > Thanks for your comment.
>
> Righto.
>
> Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: 15 Mar 2001 00:23:19 GMT
[EMAIL PROTECTED] (David Schwartz) wrote in
<[EMAIL PROTECTED]>:
>
>
>"SCOTT19U.ZIP_GUY" wrote:
>
>> > You either trust your encryption or you don't. IMO, the
>> > uncomprsesed
>> >data is _much_ more likely to contain vulnerabilities than the
>> >compressed data is.
>
>> I don't think it a question of trust or not. History has proved
>> over and over again that blind trust is for fools. One should have
>> a level of trust in one encryption method. But that does not mean
>> one should be lax about things that weaken the method.
>
> You know those cheap chain slide locks kids sometimes use to keep
> their
>parents out of their room? The ones you can easily push through or open
>with a thumbtack and rubber band? Would you put one on your front door?
>If you felt your front door needed another lock, then you should get a
>real lock. The only thing such a lock could possibly do is give you a
>false sense of security.
>
> In this case, it actually weakens things. Uncompressed data is much
>more likely to contain exploitable patterns than compressed data. In
>fact, compressibility is pretty much a measure of how patterned
>something is.
>
> DS
>
You would think that uncompressed data is more likely to
contain explotable patterns. However that attacker may not
know what those patterns are. But if he know that compressor
your using then he can exploit that. Since most compressors
are not desinged to be used with encryption.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Digital enveloppe
Date: Thu, 15 Mar 2001 01:11:15 GMT
br wrote:
> It's a way to send a message that only the authorized recipient could
> read.
> Without password or Pin.
> The recipient has just to use the same software.
> And to communicate only once with the sender.
And how, exactly, does this differ from S/MIME, say? Or any other PK system?
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: NTRU - any opinions
Date: Thu, 15 Mar 2001 01:39:16 GMT
Dr. Yongge Wang wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> :> Unfortunately, I cannot agree with that. NTRU signature scheme
> :> presented in Crypto'00 was broken without any use of lattice
> :> technique.
> :> NTRU is not a lattice scheme. there might algebraic method to break
> :> it.
>
> : NTRU is a knapsack scheme. The all the old knapsack schemes were
> : broken
>
> Knapsack problem is NP-complete, can you show me that the problem
> underlying the NTRU encryption and signature is NP-hard?
> If you can prove it, then come to comment on my posting.
Simply because it is *based on* the knapsack problem does not
automatically make it as hard as the knapsack problem, or else earlier
knapsack schemes would not have been broken. I don't know enough about
truncated rings to be able to prove anything about how hard NTRU is or
isn't.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited Again (long)
Date: Mon, 5 Mar 2001 21:53:08 -0800
I just have a few comments about your design. I do appreciate much of the
contrast to most modern ciphers.
It is provable that given an RNG that is perfect that your system offers a
large amount of security. However the exposure of the pRNG through the
permutation may be problematic with some pRNGs. You make several mentions of
the state, I think this needs to be clarified. The state that needs to be
considered is not necessarily the internal state of the pRNG, but instead
the number reachable output streams. Just as a truly horrid example of an
pRNG that has supremely poor qualities take a 100 megabit counter, fill it
with 100 megabits of truly random seed, to get a 32-bit output, clock the
counter, and take the top 32-bits of the counter. This will have very
obvious weaknesses, with blocks having an almost perfectly fixed
permutation, in spite of the fact that it obviously has a 100 megabit
internal state. This is only the most severe example of this class of
weakness. What your cipher idea needs is reachable state in k moves,
alternately the number of possible outputs given the input (or a portion of
the input) so far.
This can easily be expressed in the terms:
given 0...x-k, x+l...n, what are the reachable values in the x-k...x+l
locations.
I don't believe this is necessarily easily evaluated, and as the length of
the text increases more of these sets will be exposed. As you pointed out
not always clearly, however supposing a plaintext block of length B, to
offer the level of security that you have specified k*B! locations must be
reachable for some k>0. This could be problematic, while it will for obvious
reasons offer security of at least an approximation to a stream cipher made
of the pRNG.
Judging the reachable values is still potentially problematic. Take the
algorithm above (the 100 megabit counter one), we can fairly easily compute
the reachable values and the approximate distribution. Given the first
32-bits of the sequence are known these values can be trivially computed,
and we find that the reachable values have a very particular pattern, with
all pattern that are not 32 repeated bits, having extremely low probability
(within a reasonable distance). This is the other component of interest, the
probability of reaching each location.
Now because this is being used to generate a permutation, the information of
interest (to the analyst, not to the attacker) is not the raw values, but
instead which permutations those identify, and the associated probabilities.
If the number of reachable permuations is the number of possible
permutations and the probability of each of these permuations is within very
close bounds of identical this scheme will offer a significant amount of
security.
Additionally while having a 4096-bit block certainly sounds very impressive,
you do not in fact offer that much security. Instead of offering 2^4096
strength, your permutations offer 4096! strength, this is an interesting
situation because factorial grow faster than exponential. So while it sounds
particularly impressive to say 4096-bits this translates into 2^4096 (which
is ~10^1233) security, the maximum security offered is actually 4096!
(~3*10^13019) a significantly larger value. This is itself highly misleading
because as you point as several times, to avoid various other attacks the
blocks need to be bit balanced, this vastly reduces the space, I haven't
taken the time to compute the reachable space however it is vastly reduced
from 4096! and in fact cannot be higher than the reachable output states of
which there are are approximately 2^2048 bit balanced blocks (there's a
multplier in there somewhere that I missed so I'm probably off by a handful
of bits).
Compensating for this you have the permuations being formed seperately for
each block, this has it's good and bad sides. Given a pRNG there will be
some correlation between outputs at some point (this is a simple result of
finite state). To help alleviate this you have the block going through 2
complete permutations, this could have a problematic effect, primarily
because the limitations placed in the digital world commonly result on pRNGs
having some form of loop occuring at or near a multiple of 2. To help with
this I would suggest a pRNG based solution, not too long ago Wei Dei posted
code to generate value in supplied bounds. Making use of this code for
something akin to:
Global
int dropPlus = 0
Function
int randomNumber = inf
while(randomNumber > 4096)
randomNumber = Random(0, 4096+dropPlus)
dropPlus = dropPlus+1
if(randomNumber > 4096)
dropPlus = 0
endif
end while
However this will only be effective for some generators, for others it may
actually be problematic, it will however push things beyond multiples of 2.
I think this would help the pRNG resist analysis.
I am very interested in hearing what you think on the subject.
Joe
"Terry Ritter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Dynamic Transposition Revisited Again
[snip paper]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: qrpff-New DVD decryption code
Date: Thu, 15 Mar 2001 02:05:38 GMT
Jean-Pierre Moreau wrote:
>
> A consideration that decided me to copy and download copyrighted music
> is the powerful legal and media propaganda from 'the music industry'.
> Before, I did bought what I wanted to possess.
>
> In a market economy, prices should be down when, say, new technologies
> enable production at lower prices. New technologies now permit very
> cheap diffusion of music. Powerful Music Conglomerates are only
> distributors, even if they incidentally own rights on music by
> contracts. So how is it that we pay, say 5$ or 12$ (on, say, 15$ for a
> a music CD) to the distributor, when the actual cost of distributing
> by new means is much cheaper, say 0.25$ ?
When you go to a fast food place, and pay a couple dollars for a soda,
when it actually costs them a few cents, does that piss you off?
> Because market economy fails when there are Monopolies (or equivalent
> to monopolies). When they exist, they nearly define legality (legality
> differs from moral/ethical consideration, as Douglas A. Gwyn maked the
> remark).
Do you believe that all fast food places are part of one huge monopoly?
After all, it costs them $0.05 for a cup of soda, and they sell it to
you for over 20x that price! Or a salad which costs them $0.15, and
they sell it for $3.25!
For a food place, the food itself costs next to nothing, the utility
bills are also a low fraction of costs. What costs money is the cooks,
waiters, busboys, cashiers, managers, etc.
> Why people and small companies working in an obsolete technology
> should go in something else, but not very large Corporation? Because
> they are Monopolies.
I'm sure this question could be asked of quite a few industries, not
just music, and I doubt that most of those are monopolies.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Digital enveloppe
Date: Thu, 15 Mar 2001 02:07:54 GMT
"br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> It's a way to send a message that only the authorized recipient could
> read.
> Without password or Pin.
> The recipient has just to use the same software.
What if an attacker uses the same software?
> And to communicate only once with the sender.
> Sample : If I send you a simple message the first time and you answer me
> using the same software. You don't need any password to read my message.
> And vice versa.
> No one can read the message. Only your computer. You can't read the
> message in other computers.
> I hope it was clear.
How do you authenticate the message without prior communication?
Tom
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Wed, 14 Mar 2001 18:09:22 -0800
Dan Hargrove wrote:
>
> This was Sam Tolvanen's (the author of Eraser) response to my point about
> the question of using pseudo-random data for the random passes;
>
> From: [EMAIL PROTECTED] (Sami Tolvanen)
> Newsgroups: alt.comp.freeware
> Subject: Re: A freeware progie to ERASE data...
>
> On 13 Mar 2001 19:09:33 GMT, Dan Hargrove <[EMAIL PROTECTED]> wrote:
> >The reason I would use it, is that it has the "Gutman" method of
> >overwriting, though not perfectly implemented, as it uses pseudo-random
> >data for the random passes, rather than perfectly random data.
>
> Any random data created using arithmetic means is called pseudorandom,
> and it is pretty much the best we can do with computers, especially if
> large amount of random data is required. You may want to read Donald
> Knuth's The Art of Computer Programming, Volume 2 for more information
> about the subject.
>
> Eraser uses cryptographically strong pseudorandom data created with
> ISAAC prng for overwriting. This should satisfy even the most demanding
> users, if not, anyone is free to modify the source code to fit their
> needs.
>
> As a side note, Dr. Gutmann's paper mentions that cryptographically
> strong randomness is required only when deciding the order of the 27
> deterministic overwriting passes. Therefore, Eraser not only meets the
> requirements when it comes to the quality of random data used, it
> exceeds them.
>
> --
> Sami Tolvanen
> http://www.tolvanen.com/sami/
I do not understand the Dr.'s recommendations as you do.
I believe he decided on these particular overwrite sequences because
they address the particular peculiarities of legacy and modern hard
drive write head drifts.
If you use other random sequences of overwrite data and do not use
these 27 sequences specifically recommended for his stated purpose
then you do not necessarily exceed his protocol but in fact most
probably diminish the effect of your overwriting.
This is elementary logic which leads me to conclude you are hyping
that other software in fulfillment of some sort of personal agenda.
------------------------------
From: Sean Dwyer <[EMAIL PROTECTED]>
Subject: Porta algorithm
Date: Thu, 15 Mar 2001 02:17:02 GMT
Can anyone give me an algebraic algorithm for della Porta
encipherment/decipherment? I'm writing some classical ciphers in Python, and
this one has me stumped. Alternatively, point me towards a source that will,
please.
thankyou,
--
Sean Dwyer <[EMAIL PROTECTED]>
CAN Admin <[EMAIL PROTECTED]>
Web: http://ewe2.cvis.com.au/
------------------------------
Subject: Re: Digital enveloppe
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Thu, 15 Mar 2001 02:22:50 GMT
br <[EMAIL PROTECTED]> wrote:
> It's a way to send a message that only the authorized recipient could
> read.
> Without password or Pin.
> The recipient has just to use the same software.
> And to communicate only once with the sender.
> Sample : If I send you a simple message the first time and you answer me
> using the same software. You don't need any password to read my message.
> And vice versa.
> No one can read the message. Only your computer. You can't read the
> message in other computers.
> I hope it was clear.
Well, if I were to combine this with what you've said before (ignoring
the GPS-part, that just don't work without trusted Mission
Impossible-type hardware that contains a GPS-recieve and that will blow
up if anyone tries to open it and that can verify that no false data is
being sent to it; which simply can't be done, at least not without
mixing in some PK-system and external connections) we end up with this:
A program on your computer takes a look around to see what the hardware
looks like, then using the "uniqueness" of what is available (serial#'s,
what's there, and so on) creates a password. That password is then sent
to your friend, which from then on can send encrypted e-mails that
should only be able to be decrypted at the target computer.
Ignoring such fun things as you not being able to upgrade your computer
without breaking the system we have the problem with you sending out the
same password to everyone. That is of course easily dealt with by you
adding a randomstring to the password sent to every, but then you need
to keep track of whom got what "randomstring"... So then you're back to
having to keep a list of passwords, which can easily be dealt with using
your software (and without locking it to a single computer, which adds
no real security and breaks easily)... but that is in fact just crypto
that predates PK-systems.
So... what you've invented is in fact... what?! A program that create
and send out passwords without the user having to pick passwords?
/Tony
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Thu, 15 Mar 2001 02:23:07 GMT
Michael Brown wrote:
[snip]
> As this cipher obviously isn't a good place to try to figure out
> linear cryptanalysis, do you have any suggestions? All I can find with
> google is the theory, which is quite hard to figure out without
> something to try it out on!
FEAL-4 is a pretty good candidate for practicing either linear or
differential analysis.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Porta algorithm
Date: Wed, 14 Mar 2001 18:33:17 -0800
Sean Dwyer wrote:
>
> Can anyone give me an algebraic algorithm for della Porta
> encipherment/decipherment? I'm writing some classical ciphers in Python, and
> this one has me stumped. Alternatively, point me towards a source that will,
> please.
Since you evidently have Vigenere straight, here's the decryption algorithm
for that in C, to use for comparison:
case VIGENERE:
case GRONSFELD:
*t = 'a' + (*s - 'a' + 26 - key[i % keylen]) % 26;
break;
t is the plaintext, s is the ciphertext pointer, i is the key index.
For 26-letter Porta:
case PORTA:
if (*s < 'n')
*t = 'n' + ((*s - 'a') + key[i % keylen]) % 13;
else
*t = 'a' + (13 + (*s - 'n') - key[i % keylen]) % 13;
break;
Note that Porta's original method used 22 letters (no JKUW), so you may
need to adjust this a little and re-map the alphabet if you're trying to
stay true to De Furtivis Literarum.
--
Jim Gillogly
Highday, 23 Rethe S.R. 2001, 02:27
12.19.8.0.18, 5 Edznab 1 Cumku, Ninth Lord of Night
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Thu, 15 Mar 2001 15:58:09 +1300
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Michael Brown wrote:
> [snip]
> > As this cipher obviously isn't a good place to try to figure out
> > linear cryptanalysis, do you have any suggestions? All I can find with
> > google is the theory, which is quite hard to figure out without
> > something to try it out on!
>
> FEAL-4 is a pretty good candidate for practicing either linear or
> differential analysis.
A quick search on Google showed a lot of good stuff on this one. Thanks!
>
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
---
Michael Brown
Physics is no fun if you disregard friction.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 6 Mar 2001 11:44:53 -0800
Crossposted-To: alt.hacker
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The fclose() flushes the buffers.
fclose() only flushes the buffers from the executable, that leaves only OS,
SCSI card, and Hard Disk caches
As evidence of this just run a simple little program:
//put various extra code here
FILE *out;
out = fopen("AFileThatIsntOnYourSystem.bin", "wb");
fprintf(out, "a");
fclose(out);
int ec = MoveFile("AFileThatIsntOnYourSystem.bin",
"newNameThatYouDontHave.bin");
printf("%i\n", ec);
//and here
You'll find that ec very rarely returns valid so quickly, inspite of the
fact that fclose will return success. The timing will also vary widely,
Win9x will succeed in moving the file generally sooner than NT (the
equivalent code on Unix varients works the first time), sometimes you can
have a period of several seconds where the program cannot move the file
because of sharing violations (you can use GetLastError to get the code).
> So explain to us which buffers
> are not flushed and why you think then that these are the ones that
> are used by the conniving OS to conspire to not write to the hard
> drive as the code instructions demand.
This happens because the operating is under no force to immediately push
your data to the disk, writes are expensive, why not put them off until the
system is idle.
> We don't agree. This is all off topic.
This whole thread has debatable quantities of on/off-topicness for both the
written to groups.
> Well, there you go again. You are making another hypothetical to
> detract from the fact that you cannot stick with the thread.
Do you prefer mine which is far from hypothetical? Mine has very noticable
consequencs for numberous systems, yours included.
>
> This is a personal use program for windows. I think it is fair to
> say this program is for and intended for a non multitasking
> environment.
Doesn't really matter, even most personal computers are run multi-tasking
these days, let me give you an example from the machine I'm on (a windows
2000 server box that is for only my use) 38 processes, that's how many
different programs are executing right now.
> Take a look at my floppy disk test results I just posted.
Your floppy tests are flawed. You test only the situation where you examine
the final state of the file, which will reflect the last written data,
however you have not put it through a full forensic examination that could
show how many times it was written, you have not debugged the OS to see if
it is immediately flushing the cache to disk, etc.
How's this, take the code
for(int i = 0; i >= 0; i++)
{
FILE *out = fopen(you know the drill)
fseek(out, 0, SEEK_SET)
fwrite(&i, sizeof(int), 1, out);
fclose(out);
}
If you are correct, this should take 3*2^31/(RPMs of your drive) seconds to
execute approximately (I assume we both agree that fseek doesn't actually go
to the disk). If there is write caching occuring, this will happen much
faster. You can run it for yourself, and see that it will happen very much
faster than 890 thousand seconds (assuming 7200 RPM drive). This simply
amplifies the effects to the point where they can be easily measured.
> They seem
> to cramp everything pretty much all the detractors have been saying.
Actually they only show that the last data that is written gets written to
the disk, which is exactly what has been said all along.
>
> Let's see you come up with some more off topic hypothetical BS
> refuting this floppy test.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: AES and DES
Date: Tue, 6 Mar 2001 12:15:01 -0800
In truth there isn't much similarity between them. They can however be
compared:
DES has a 56-bit key, operates on a 64-bit block, is a
substitution-permutation network, and has resisted all known analysis to at
least 2^48 work, at 21+ years old, it is now old enough to legally drink in
the state of california, and it shows through the use of old concepts for
many portions of the algorithm. There is a more recent update of this 3DES
that takes either 2 or 3 keys depending on implementation and is constructed
as Encrypt(Decrypt(Encrypt(data, key), key), key) where key is actually
either 2 or 3 seperate keys.
AES has a key of 128, 192, or 256 bits, operates on a 128-bit block
(although Rijndael, it's pre-AES name, is also specified for 192, and
256-bit blocks), so far it has resisted all analysis of the full cipher.
It's main detracter is that is is very new, having only been examined for a
couple of years now. It is significantly faster than 3DES and may be faster
than DES in general software.
We can examine them much deeper, but DES is no longer recommended for
anything above kid-sister grade security (that's security to keep your
kid-sister out of your private files), 3DES is an extremely safe choice
cryptographically it has 2 decades of analysis behind it and offers 2^90+
security. Rijndael/AES is new, it's fast, it's the next standard, but it
hasn't been around long enough for us to know if it can really fight.
My personal opinions of the matter are that I think Rijndael will hold up
well, but not perfectly. I recommend that anyone using it uses a strong
chaining mode, and still stays under the 2^91 bits mark. That point has
various degrees of meaning, going above that point you begin to see language
patterns start to emerge from a 128-bit block cipher. These pattern will
begin around 2^64 blocks, however I expect that Rijndael resistance to
analysis of this language will be sufficient for 2^84 blocks ( 2^91 bits ).
This will not be an issue for the forseeable future, it will take 2^84 work
to make those blocks, or 700,000+ years at the rate of the RSA DES Challenge
III, and storing those blocks would take 2^60 gigabits or only a few billion
times the size of your hard drive.
3DES on the other hand will start to show language patterns at 2^56 blocks,
the difficulty of examination is so far excessively high, and the best that
can be done is 2^90 work.
DES is the last of the bunch. Forget language patterns, forget
cryptanalysis, RSA DES Challenge III 22 hours 15 minutes, brute force. They
just tried every key until they got it to decrypt properly, and the machine
cost less than $250,000.
Joe
"Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi
>
> As I told in my previous submission, I am begining in Crypto.
> I red some stuff about AES that will replace DES.
> Can somebody explain me the differecences and the advantages.
> A brief dicuss or some useful links with this informations.
> Regards
>
> Latyr
>
>
>
------------------------------
** 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
******************************
