Cryptography-Digest Digest #619, Volume #14 Fri, 15 Jun 01 18:13:00 EDT
Contents:
Any good Crypto Books? (Jeff Potts)
Re: The 94 cycle cipher (Fat Phil)
Re: Any good Crypto Books? ("Tom St Denis")
Re: Any good Crypto Books? (John Savard)
Re: CipherText E-mail encryption ("Prichard, Chuck")
Re: CipherText E-mail encryption ("Joseph Ashwood")
Re: CipherText E-mail encryption ("Tom St Denis")
Re: integration question (John Myre)
Re: CipherText E-mail encryption ("Prichard, Chuck")
Re: integration question (Paul Rubin)
Re: Substitution Humor! ("Boyd Roberts")
Re: CipherText E-mail encryption ("Boyd Roberts")
Re: integration question ("Tom St Denis")
Re: integration question ("Boyd Roberts")
Re: integration question (Fat Phil)
Re: integration question ("Tom St Denis")
Re: integration question ("Robert J. Kolker")
Re: survey ("Joseph Ashwood")
Is ECB truly more secure than CBC? (lcs Mixmaster Remailer)
Re: Is ECB truly more secure than CBC? ("Tom St Denis")
Re: Is ECB truly more secure than CBC? ("Paul Pires")
Re: HELP WITH RSA ENCRYPTION/DECRYPTION INCLUDING GARNER CRT ALGORITHM ("Boyd
Roberts")
Re: CipherText E-mail encryption ("Prichard, Chuck")
Re: Is ECB truly more secure than CBC? (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jeff Potts)
Subject: Any good Crypto Books?
Date: 15 Jun 2001 12:15:54 -0700
I'm trying to get a better understanding of Cryptography and it's uses
within Security. I did a search for Cryptography books and there seems
to be few out there.
One named "Applied Cryptography", seemed to be more directed only to
software developers. There was another one I saw named "RSA's Official
Guide to Cryptography", that seemed to cover a great number of topics,
not only Cryptography, but security protocols as well.
I guess my question is, has anyone read either of these? If so, which
would be best to learn Cryptography and Security Protocols? Or would
one look at completely different books?
-Jeff
------------------------------
From: Fat Phil <[EMAIL PROTECTED]>
Subject: Re: The 94 cycle cipher
Date: Fri, 15 Jun 2001 22:05:47 +0300
Tom St Denis wrote:
>
> Phil Carmody wrote:
> > You're computation bound so that the above probably has little or no
> > real effect on an out-of-order processor. However I'm sure that you
> > could trivially do two blocks in almost the same time as you do 1!
> > Remember that there are 32x32->32 multiply instructions in the >386 with
> > any register as the destination.
>
> That's only IMUL IIRC.
YRC
:-)
Phil
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Any good Crypto Books?
Date: Fri, 15 Jun 2001 19:17:43 GMT
"Jeff Potts" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm trying to get a better understanding of Cryptography and it's uses
> within Security. I did a search for Cryptography books and there seems
> to be few out there.
>
> One named "Applied Cryptography", seemed to be more directed only to
> software developers. There was another one I saw named "RSA's Official
> Guide to Cryptography", that seemed to cover a great number of topics,
> not only Cryptography, but security protocols as well.
>
> I guess my question is, has anyone read either of these? If so, which
> would be best to learn Cryptography and Security Protocols? Or would
> one look at completely different books?
Both Applied Crypto and the Handbook of Applied Crypto touch on the
theoretical side of crypto. They are good books, references, etc...
Hmm books on actual cryptosystems? I dunno. It's not a popular topic.
[not buzzward compliant!]
Tom
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Any good Crypto Books?
Date: Fri, 15 Jun 2001 19:20:37 GMT
On 15 Jun 2001 12:15:54 -0700, [EMAIL PROTECTED] (Jeff Potts) wrote,
in part:
>One named "Applied Cryptography", seemed to be more directed only to
>software developers.
Many people have read this one, and it's generally considered to be
one of the best all around, since it has a lot of information in it.
It depends on what you are looking for, though.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Fri, 15 Jun 2001 19:24:01 GMT
It could be that the lookup method uses the "if case then" structure
without an exit if resolved.
This method could be improved using a more direct hash referencing
method.
I'll bet it can be improved immensely.
-C. Prichard
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Fri, 15 Jun 2001 12:21:37 -0700
Actually I would second Tom's suggestion. VB is extremely slow for
performing operations that don't land on what Microsoft considers basic
lines. This most likely means that they coded a Base-64 encoder that very
quickly encodes plain text files, but rely on a very slow, very old, very
kludgy Base-64 encoder for more advanced thigns like Base-64 encoding 0x00.
Your best bet would be to move to a different, more powerful (in terms of
cryptograhy) language.
Joe
"Prichard, Chuck" <[EMAIL PROTECTED]> wrote in message
news:GarW6.1187$[EMAIL PROTECTED]...
>
> > > I am experiencing an unusual delay in encoding larger (20KB) CXT
> files
> > > with BASE-64.
> > >
> > > The same RTF plaintext file is encoded very rapidly.
> > >
> > > Any ideas?
> >
> > Don't use Visual Basic?
> >
> > Tom
> >
> VB does the encoding quickly on a plaintext RTF while it takes much, much
> longer on CXT.
>
> ??? I wonder why. No spaces in the CXT??? It seems odd.
>
> -C. Prichard
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Fri, 15 Jun 2001 19:31:22 GMT
"Prichard, Chuck" <[EMAIL PROTECTED]> wrote in message
news:lhtW6.1198$[EMAIL PROTECTED]...
> It could be that the lookup method uses the "if case then" structure
> without an exit if resolved.
>
> This method could be improved using a more direct hash referencing
> method.
>
> I'll bet it can be improved immensely.
Yes.
My base64 encoder from my CDLL package [which has not be released]
/* base64 encode */
void EXP base64_encode(const unsigned char *input, long inlen,
unsigned char *output, long *outlen)
{
long x, i;
unsigned long y;
*outlen = 0;
for (x = 0; x < inlen; ) {
for (y = i = 0; (i < 3) && (x < inlen); i++)
y = (y<<8) | input[x++];
/* shift as required */
if (i != 3) y <<= (8 * (3 - i));
output[(*outlen)++] = code[y&63]; y>>=6;
output[(*outlen)++] = code[y&63]; y>>=6;
output[(*outlen)++] = code[y&63]; y>>=6;
output[(*outlen)++] = code[y&63];
}
output[(*outlen)++] = 0;
}
This runs very very quickly.
Tom
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: integration question
Date: Fri, 15 Jun 2001 13:28:50 -0600
Paul Rubin wrote:
<snip>
> Your next book to read is "Calculus", by Michael Spivak, 2nd ed.,
> Publish or Perish Press. Accept no substitutes.
I *loved* that book. We used it in freshman calculus. I don't
know if Tom will like it or not, though. It depends on a
certain frame of mind regarding mathematics: "why is this true"
rather than "what do we know" or "how can we compute this".
Some of my classmates never really understood.
> You might have to look for a used copy.
(I'm not giving mine up.)
JM
P.S.
Does anybody understand the reference to Yellow Pig?
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Fri, 15 Jun 2001 19:42:13 GMT
For datafile security it is decided that the best solution is to use a
uniform key to encrypt all application data. To counter the obvious
vulnerability, users will be encouraged to simply remove the datafiles by
using a program feature to make it convenient. Any alterations to contact
information and preferences will require making new copies of the stored
data from time to time.
The user will be emphatically informed about this vulnerability and the
need to provide adequate measures of protection as the ONLY possible line
of defense.
As for other criticisms about the security rendered by the CipherText
string encryption algorithm, they are merely unfounded speculation based
on comparisons with stronger methods of byte encryption. No attack has
EVER been suggested, nor has any attack been made resulting in a broken
CXT message.
Until recently it has not been practical to examine a recurring cipher
bit pattern in a CXT file. That has changed. CipherText is more open to
attacks based on information obtained through analysis of the recurring
pattern of applied bits.
We all know that CipherText has a very limited key domain compared to
other ciphers.
We all know that CipherText provides a lesser degree of security.
In my view that does not diminish the usefulness of the string encryption
algorithm for use in common messaging to provide ordinary people with a
very reasonable measure of message security. It is an important task, and
the algorithm will be subject to all kinds of criticism. But for now it
is there, yet unbroken as a demonstration for all to see of what can
possibly be achieved.
-C. Prichard
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: integration question
Date: 15 Jun 2001 12:44:12 -0700
John Myre <[EMAIL PROTECTED]> writes:
> > Your next book to read is "Calculus", by Michael Spivak, 2nd ed.,
> > Publish or Perish Press. Accept no substitutes.
>
> I *loved* that book. We used it in freshman calculus. I don't
> know if Tom will like it or not, though. It depends on a
> certain frame of mind regarding mathematics: "why is this true"
> rather than "what do we know" or "how can we compute this".
I think it's the right book for Tom. The 2nd edition is preferable
but if the 1st ed. is what you can find, then get that.
> P.S.
> Does anybody understand the reference to Yellow Pig?
Yes. Also the one to K. Klingenstein. :)
------------------------------
From: "Boyd Roberts" <[EMAIL PROTECTED]>
Subject: Re: Substitution Humor!
Date: Fri, 15 Jun 2001 21:45:24 +0200
"Douglas A. Gwyn" <[EMAIL PROTECTED]> a écrit dans le message news:
[EMAIL PROTECTED]
> Tray droll.
ouais, vachement tray droll.
------------------------------
From: "Boyd Roberts" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Fri, 15 Jun 2001 21:49:36 +0200
"Prichard, Chuck" <[EMAIL PROTECTED]> a écrit dans le message news:
pytW6.1199$[EMAIL PROTECTED]
> For datafile security it is decided that the best solution is to use a
> uniform key to encrypt all application data.
oxymoron. a single key? are you mad?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: integration question
Date: Fri, 15 Jun 2001 19:51:02 GMT
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> John Myre <[EMAIL PROTECTED]> writes:
> > > Your next book to read is "Calculus", by Michael Spivak, 2nd ed.,
> > > Publish or Perish Press. Accept no substitutes.
> >
> > I *loved* that book. We used it in freshman calculus. I don't
> > know if Tom will like it or not, though. It depends on a
> > certain frame of mind regarding mathematics: "why is this true"
> > rather than "what do we know" or "how can we compute this".
>
> I think it's the right book for Tom. The 2nd edition is preferable
> but if the 1st ed. is what you can find, then get that.
Hmm I will look into it. My school has several texts on [applied] calculus.
My own text for my Math I/II covers Calculus in some depth (differentials,
differential linear systems, integration of various kinds). I haven't read
it all since I am still covering Math I which is basic algebra (i.e polar
equations, quadratic systems, basic trig)
Tom
------------------------------
From: "Boyd Roberts" <[EMAIL PROTECTED]>
Subject: Re: integration question
Date: Fri, 15 Jun 2001 21:56:21 +0200
"Mok-Kong Shen" <[EMAIL PROTECTED]> a écrit dans le message news:
[EMAIL PROTECTED]
> I deduce that there is highly probably quite a difference
> in school education between Canada and US. Douglas Gwyn
> just told us he was able to read most of Principia
> Mathematica in high school.
the difference is not the education system. the difference
is doug gwyn. one smart individual.
------------------------------
From: Fat Phil <[EMAIL PROTECTED]>
Subject: Re: integration question
Date: Fri, 15 Jun 2001 22:57:07 +0300
Tom St Denis wrote:
> I wanted to proof
>
> Sum(x^3) = Sum(x)^2
>
> Where Sum() is the sum of the expression overall a series of consecutive
> values of 'x' [say 0..99].
This is an induction proof.
1) Prove the base case (x=0 or 1 usually).
2) Prove that for arbitrary n if it is valid for case n, then it is
valid for case n+1 also.
That's it - proved for all n.
As an example of it's use:
We are required to prove that in any set of horses, all will be the same
colour.
2) The induction step - Let us assume that for arbitrary n, any set of
n horses contains only horses of the same colour. Take a set of n+1
horses. Remove any horse, and by our assumtion they will all be the same
colour. However, we could have removed any horse, so any one that we
remove will be in the set of n horses that are of the same colour if we
were to have removed a different horse. And therefore all n+1 horses are
the same colour.
1) The base case - a set of one horse has all horses the same colour.
This is a famous 'misuse' of induction, can you see the mistake?
Phil
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: integration question
Date: Fri, 15 Jun 2001 19:59:40 GMT
"Fat Phil" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > I wanted to proof
> >
> > Sum(x^3) = Sum(x)^2
> >
> > Where Sum() is the sum of the expression overall a series of consecutive
> > values of 'x' [say 0..99].
>
> This is an induction proof.
> 1) Prove the base case (x=0 or 1 usually).
> 2) Prove that for arbitrary n if it is valid for case n, then it is
> valid for case n+1 also.
> That's it - proved for all n.
>
>
> As an example of it's use:
>
> We are required to prove that in any set of horses, all will be the same
> colour.
>
> 2) The induction step - Let us assume that for arbitrary n, any set of
> n horses contains only horses of the same colour. Take a set of n+1
> horses. Remove any horse, and by our assumtion they will all be the same
> colour. However, we could have removed any horse, so any one that we
> remove will be in the set of n horses that are of the same colour if we
> were to have removed a different horse. And therefore all n+1 horses are
> the same colour.
There is no constraint that the set of n+1 must have the same colour.
Tom
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: integration question
Date: Fri, 15 Jun 2001 16:00:39 -0400
Tom St Denis wrote:
> "Robert J. Kolker" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> >
> > Tom St Denis wrote:
> >
> > >
> > > Another question: Can integration be performed over non-continuous
> domains?
> > > i.e the integers?
> >
> > Descrete sums can be performed. For an infinite number of terms
> > you have to worry about convergence. In the formal sense sums
> > and integrals have a similarity. They are both linear operators,
> > sums and finite difference relate in a way similar to integrals and
> > derivatives.
>
> I noticed this. I wanted to proof
>
> Sum(x^3) = Sum(x)^2
>
> Where Sum() is the sum of the expression overall a series of consecutive
> values of 'x' [say 0..99].
>
> I proved it using
>
> Sum(x) = x(x - x_0)/2 = x(x - 0)/2 = x^2/2
> Sum(x)^2 = (x^2/2)^2 = x^4/4
>
> Then
>
> Sum(x^3) = Int(x^3 dx) = x^4/4
>
> Thus QED.
>
> Is that valid?
No.
The analogy of between summation and integration goes
just so far. Integral t dt [from 0 to x] = x^2/2
Sum of k from 0 to n = n(n+1)/2.
The expressions are of the same polynomial order but
not identical.
Bob Kolker
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Fri, 15 Jun 2001 13:50:47 -0700
Unfortunately I found an attack this morning on and have to revisit several
decisions to see if it's even valid any more, so I may have to scrap it.
Without going into details on the cipher, I found an attack where although
across outputs it was (within experimental tolerances of) SAC inside a round
there was partial information revealed about the state, information that
after a few gigaoutputs would lead to an attack.
Once I've reworked it and determined if there's anything there that can be
salvaged I'll get down to proper definitions.
Joe
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:JwbW6.119560$[EMAIL PROTECTED]...
> I would be interested in seeing pseudo code.
>
> Personally I would make a new stream cipher based on a LFSR or LFG since
> they have known periods and decent statistical properties. All you have
> todo is make a correlation or linear attack hard.
>
> I have 8x1 sboxes you could use if you want to compress bits. They are
not
> made with correlation immunity in mind [primarily because I don't know
that
> that means]. they are nonlinear and SAC compliant.
>
> SAC means Strict Avalanche Criterion. I.e flipping any input bit (any
> single) will flip the output bit 1/2 of the time.
>
> I presume correlation immunity would mean the output is 0 or 1 with a prob
> of 1/2 when any combo of bits (less than 8) are held constant. But that's
> just a guess ...
>
> Tom
>
>
------------------------------
Date: 15 Jun 2001 21:20:10 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Is ECB truly more secure than CBC?
Someone named Joseph Ashwood is posting to the XML Encryption list,
presenting himself as a cryptography expert. In his most recent posting
he offers an argument as to why ECB mode should be supported in addition
to CBC! Will any respected cryptographers speak up to say that this is
a credible argument?
The XML encryption standard could end up seeing widespread use on
the Internet. Should someone who supports the use of ECB mode be
considered an expert in a forum where not everyone is knowledgeable
about cryptography? It is very worrisome what form the standard will
end up taking when this is what passes for expert cryptographic advice.
His posting is below. Comments are appreciated.
Ashwood posting:
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Date: Fri, 15 Jun 2001 12:15:41 -0700
Subject: Thoughts on CBC
I've been considering for a while now what evidence I could give to prove
that under certain circumstances CBC is less secure under an attack type
than ECB. I have finally found one, it should have been obvious from the
beginning to me but it took this long.
The example should be fairly familiar to everyone here; encrypting XML with
3DES is weaker under a key recovery attack when using CBC than it is with
ECB. To prove this you need to know that the key recovery attacks on 3DES
take knowledge of > 2^56 known pairs. With XML we only have 67 basic symbols
that are likely to be present (the base-64 encoding characters and <,>,/)
outside of that the probability is exceedingly low. This means that the
64-bit block of 3DES can only contain 67^8, that number is less than 2^49,
which is significantly lower than the needed 2^56, the attack cannot be
mounted against XML/3DES/ECB.
However moving to CBC, the actual number of input blocks that can be
encrypted rise to 2^64. With 2^64 possible texts the attack can be mounted.
This is one situation where ECB is actually more secure under an attack than
CBC. It should not be too much of a worry because the attack takes 2^90
work, but it is an example of where extremely careful selection of the
chaining mode can actually offer a slight improvement in some form of
security.
The counter-argument is that it will only take 2^49 texts to begin a
language based attack on XML/3DES/ECB, where it will take 2^64 texts to
begin the same attack on XML/3DES/CBC. This argument only applies where the
information is more important than the key. This may or may not be the case.
Like my other extremely recent posting this should not change our decisions
just present an argument for maintaining a tendancy towards diversity.
Joe
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Fri, 15 Jun 2001 21:29:23 GMT
"lcs Mixmaster Remailer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Someone named Joseph Ashwood is posting to the XML Encryption list,
> presenting himself as a cryptography expert. In his most recent posting
> he offers an argument as to why ECB mode should be supported in addition
> to CBC! Will any respected cryptographers speak up to say that this is
> a credible argument?
His argument makes sense but its not practical. I would rather use CTR than
CBC or ECB modes. If I had to pick though I would rather use CBC .
> The XML encryption standard could end up seeing widespread use on
> the Internet. Should someone who supports the use of ECB mode be
> considered an expert in a forum where not everyone is knowledgeable
> about cryptography? It is very worrisome what form the standard will
> end up taking when this is what passes for expert cryptographic advice.
This I highly disagree with. Why is it when someone reinvents the wheel it
will "be the next big standard". Encrypted content on the web ALREADY
exists.
In fact PHP/ASP/XML are all re-inventions of HTML+Perl. Encrypted content
via SSL already exists and is used widely.
Tom
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Fri, 15 Jun 2001 14:31:51 -0700
You should be more concerned with mis-representing someone elses
statements. I have read the post and I see no reason for your concern
nor do I view it as you represent it to be.
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Someone named Joseph Ashwood is posting to the XML Encryption list,
> presenting himself as a cryptography expert.
He's one of the folks I listen to. Who are you? I doubt your mother named you
"lcs Mixmaster Remailer "
>In his most recent posting
> he offers an argument as to why ECB mode should be supported in addition
> to CBC! Will any respected cryptographers speak up to say that this is
> a credible argument?
Which respected cryptographers will you listen to?
>
> The XML encryption standard could end up seeing widespread use on
> the Internet. Should someone who supports the use of ECB mode be
> considered an expert in a forum where not everyone is knowledgeable
> about cryptography? It is very worrisome what form the standard will
> end up taking when this is what passes for expert cryptographic advice.
What advice were you looking for? I find it comforting to listen to someone
who can objectively examine all sides of an issue. The line below is a hint.
> Like my other extremely recent posting this should not change our decisions
> just present an argument for maintaining a tendancy towards diversity.
> Joe
If you wish to refute his observation, do so.
>
> His posting is below. Comments are appreciated.
Take Prozac.
Paul
>
> Ashwood posting:
>
> From: "Joseph Ashwood" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Date: Fri, 15 Jun 2001 12:15:41 -0700
> Subject: Thoughts on CBC
>
> I've been considering for a while now what evidence I could give to prove
> that under certain circumstances CBC is less secure under an attack type
> than ECB. I have finally found one, it should have been obvious from the
> beginning to me but it took this long.
>
> The example should be fairly familiar to everyone here; encrypting XML with
> 3DES is weaker under a key recovery attack when using CBC than it is with
> ECB. To prove this you need to know that the key recovery attacks on 3DES
> take knowledge of > 2^56 known pairs. With XML we only have 67 basic symbols
> that are likely to be present (the base-64 encoding characters and <,>,/)
> outside of that the probability is exceedingly low. This means that the
> 64-bit block of 3DES can only contain 67^8, that number is less than 2^49,
> which is significantly lower than the needed 2^56, the attack cannot be
> mounted against XML/3DES/ECB.
>
> However moving to CBC, the actual number of input blocks that can be
> encrypted rise to 2^64. With 2^64 possible texts the attack can be mounted.
>
> This is one situation where ECB is actually more secure under an attack than
> CBC. It should not be too much of a worry because the attack takes 2^90
> work, but it is an example of where extremely careful selection of the
> chaining mode can actually offer a slight improvement in some form of
> security.
>
> The counter-argument is that it will only take 2^49 texts to begin a
> language based attack on XML/3DES/ECB, where it will take 2^64 texts to
> begin the same attack on XML/3DES/CBC. This argument only applies where the
> information is more important than the key. This may or may not be the case.
>
> Like my other extremely recent posting this should not change our decisions
> just present an argument for maintaining a tendancy towards diversity.
> Joe
------------------------------
From: "Boyd Roberts" <[EMAIL PROTECTED]>
Subject: Re: HELP WITH RSA ENCRYPTION/DECRYPTION INCLUDING GARNER CRT ALGORITHM
Date: Fri, 15 Jun 2001 23:36:29 +0200
"cohalloran" <[EMAIL PROTECTED]> a écrit dans le message news:
[EMAIL PROTECTED]
> You must be french.
nope.
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Fri, 15 Jun 2001 21:54:06 GMT
Because of the problems associated with keeping the config options
simple, it is decided to use an approach that relies on a user's own
security measure as the ultimate assurance of data privacy.
It can be made an option in a future release, but to introduce the easily
configurable product its important to offer encryption of the user
configurable HDD preference and contacts information.
By requiring both a password and key to login, I doubt the product will
be popular at all.
Its possible that you could whip up some kind of solution that derives
the encryption key using the password, but the option to inform the user
about the need to protect the contacts datafile on the HDD is simply,
much easier to implement.
The urge to develop a simpler application outweighs any other. The more
sophisticated feature can be implemented after it is developed. Until
then, beginning with the option to secure the computer itself and by
removing the data thought to be vulnerable seems very plausible.
-C. Prichard
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is ECB truly more secure than CBC?
Date: 15 Jun 2001 21:50:15 GMT
[EMAIL PROTECTED] (lcs Mixmaster Remailer) wrote in
<[EMAIL PROTECTED]>:
>Someone named Joseph Ashwood is posting to the XML Encryption list,
>presenting himself as a cryptography expert. In his most recent posting
>he offers an argument as to why ECB mode should be supported in addition
>to CBC! Will any respected cryptographers speak up to say that this is
>a credible argument?
>
>The XML encryption standard could end up seeing widespread use on
>the Internet. Should someone who supports the use of ECB mode be
>considered an expert in a forum where not everyone is knowledgeable
>about cryptography? It is very worrisome what form the standard will
>end up taking when this is what passes for expert cryptographic advice.
>
>His posting is below. Comments are appreciated.
>
>Ashwood posting:
>
>From: "Joseph Ashwood" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Date: Fri, 15 Jun 2001 12:15:41 -0700
>Subject: Thoughts on CBC
>
I don't know if this is the JOE who post here frequently trying
to pretend to be an expert but I thought his address was @msn,,,
or something along that line. As to which mode to use. I would need
to know about what XML encryption is for. ECB of plain text is
considered weaker than CBC. But not by much. Do you send fixed size
packets. Is compression invovled. Is there authenication. You have
to look at whole picture. I would assume there are far greater
security issues that if its ECB or CBC. What alogrithm is used.
What kind of data compressiom. BWT would be nice or some bijective
compression.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
** 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
******************************
