Cryptography-Digest Digest #933, Volume #11 Sat, 3 Jun 00 19:13:01 EDT
Contents:
Re: http://www.infraworks.com product ("Paul Pires")
Re: Good ways to test. (Mok-Kong Shen)
Re: Need "attack time" measurements on a toy cipher... (long) ("TheGPFguy")
Re: Good ways to test. (tomstd)
Re: Need "attack time" measurements on a toy cipher... (long) ("TheGPFguy")
Re: No-Key Encryption (Mok-Kong Shen)
Re: Good ways to test. (Mok-Kong Shen)
Re: No-Key Encryption (Mok-Kong Shen)
Re: XTR independent benchmarks (Wei Dai)
Re: Good ways to test. (tomstd)
Re: Need "attack time" measurements on a toy cipher... (long) (Baruch Even)
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: http://www.infraworks.com product
Date: Sat, 3 Jun 2000 14:52:18 -0700
I had to look at the web page,
Sorry.
"After the 45 minutes or the 1 time view, the document is shredded from your
hard drive"
Their software runs on my machine (all the time presumably) and decides to
shred documents? On my machine?
So I load the document, say an AutoCad file, for my 1 hour and then kill
their process. (CNTRL, ALT, DELETE and end task)
"* Provides total protection by destroying the content if any security
elements are violated. "
This is a good thing?
I once called Microsoft with a problem with Exchange behaving badly with
User Profiles. After many hours and constant movement up the food chain it
was explained to me that I did not have a bug but that I had actually found
an "Undocumented Feature".
I am not calling these guys.
Paul
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Good ways to test.
Date: Sun, 04 Jun 2000 00:08:57 +0200
tomstd wrote:
> You are missing the picture.
>
> Crypto: I can say a block cipher has 'X' resistance to 'Y'
> attacks.
>
> Medicine: I can say 'X' people get better and 'Y' people get
> dead.
>
> Same thing. In crypto I can say 'DES has a resistance to linear
> attacks effectively of O(2^43) work' making it 'strong'. In
> medicine I can say 99.99% people got better but 0.01% died
> making it 'a cure'.
>
> We didn't know (or now either) if DES could have been broken
> easily, same for medicine. Those 0.01% may have had kids before
> they died that have some wierd genetic disease making 0.01%
> become much larger.
>
> That's why I called it comparative. You wouldn't use FEAL-8
> over Blowfish would you? Why because given all that we know
> Blowfish is more secure. Is that definative? Not a shot in
> hell. But it's better then "What cipher will I use today?".
I wish that there are plenty of people who accept that sort of
numerical figures of yours. But please don't count on me. I don't
buy that.
> >2. I know too little about chemistry or phamacology to know
> what
> > substance you mentioned is. But apparently you were
> referring to
> > the issue of the yet unknown side effects of drugs. Yes,
> this does
> > seem to have analogy in crypto, namely the yet unknown
> > (not yet existing or already existing but secret)
> techniques of attack.
> > To that point all what I can say is to repeat my
> conviction that
> > anyone applying crypto is responsible to himself for the
> consequence
> > of what algorithm he chooses and how the whole security
> system is
> > organized and run. No other person can carry that
> responsibility
> > for him. He can gather all relevant informations that he
> can manage
> > to obtain. But he has to make his own decision (including
> such as
> > to blindly and totally rely on what a certain guru says)
> and has no
> > one but himself to blame, if that decision happens to turn
> out to
> > be wrong.
> >
>
> You're right. Companies like Entrust and RSA are *liable* for
> any damages that occur when people use their tools. So I would
> assume they are doing the best they can.
In principle the same comment as above.
M. K. Shen
------------------------------
From: "TheGPFguy" <[EMAIL PROTECTED]>
Subject: Re: Need "attack time" measurements on a toy cipher... (long)
Date: Sat, 03 Jun 2000 22:01:10 GMT
Paul Pires <[EMAIL PROTECTED]> wrote in article =
<99d_4.57122$[EMAIL PROTECTED]>...
> I know you set up a pretty good work plan for the folks in here to =
follow
> but you have to understand that no one here is very good at coloring =
inside
> the lines.
Before I continue further, let me publicly thank you for your clear and =
concise explanation of what to expect here. I mean that literally, not =
sarcastically.
>=20
> Your basic statement is self contradictory. You state that there is a =
short
> secrecy horizon, that the same key is always used and yet you claim =
the
> plaintext is unknown. All plaintext or just the stuff inside your =
security
> horizon ?
>=20
The statement is contradictory because I set up a trial that is weaker =
than the
actual situation. I also tried too hard to shorten my already-long =
posting. :-)
Only the sample uses the same key for every encryption.
The plaintext is unknown only to the attacker within the secrecy =
horizon.
> If any attribute of any past plaintext becomes known, your current =
security
> starts to fall to "defeat in detail" take for example the length of =
any one
> plaintext.
>=20
> <snip>
> 5. Iterate across this padded plaintext "P". The ciphertext is "C" =
and
> the key is "K".
> a. TempChar =3D (P[i] + C[i-1]) mod 256
> b. C[i] =3D (TempChar + K[i]) mod 256
>=20
> At the beginning of the loop, set TempChar =3D P[0].
> <endsnip>
>=20
> Unless I missed something,
>=20
> I know a P[6] (the value of the length), I know C[5] and C[6], I =
can
> solve for TempChar. I now know one of your key values K[6]. I now =
know the
> length of EVERY message you encrypt.
I should have mentioned I was starting at index 0. =20
So the first 2 iterations, unrolled, are:
T0 =3D P[0]
C[0] =3D T0 + K[0] mod 256
T1 =3D P[1] + C[0] mod 256
C[1] =3D T1 + K[1] mod 256
Okay, translating your statement to 0-based, you know C[4] and C[5]. =20
So you can solve for (TempChar + K[5]) mod 256. How did you get K[5]?
If you can't get K[5], how did you get P[5]?
I would have thought you would start by using C[0] and C[1]. =20
Or by comparing multiple ciphertexts since I was stupid enough to use =
the same key on all of them.
> If you put in the post pad to address a
> weakness, the adversary will thank you for the tip, ignore the content =
of
> the pad and look for clues in how and why you stuck it on. You are not
> making it more secure you are drawing a bullseye to the weakness.
>=20
Okay, good point.
> Don't even worry about an algorithm until you have an assessment of =
the real
> situation and the key management worked out.
>=20
This is the silver nugget that needed saying.
> Not much reason to take it past here. This was five minutes work by =
the
> slowest guy in the room. Don't beat your head on a wall. Every process =
has a
> sequence. An excerpt from the Vikings handbook, "Remember Gunther, =
It's
> rape, then pillage, then burn".
What a great quote! :-)
>=20
> You can keep patching it and reposting, or you can learn more or you =
can
> walk off in frustration. The result of the first two are the same. =
Four
> years from now you will be posting responses and wondering how heck =
you got
> here.
>=20
The goal was to learn more. =20
> Paul
>=20
> By the way, when you see the term "Stupid" associated with something =
you
> post, that's sci.crypt for "I'm not housebroken".=20
I had guessed. That's the standard definition in any population where =
the mean IQ exceeds the mean shoe size; (e.g. more than 1 sigma to the =
right of the bell curve). :-)
> If your bosses need
> security and are unwilling to invest in it, don't be a weenie, tell =
them
> they are Stupid. "Weenie" is sci.crypt for employed.
ROTFL!!! I plan to remain weenie-like for a little while and then go =
play somewhere else.
Actually, I'm trying to tell them they don't need to store this stuff in =
ciphertext, because they have so many other open doors. =20
Anyway, thanks for taking the time to provide some advice.
I'd still like to see what the attack looks like, just to learn.
But, as you've suggested, I won't belabor the point of this coloring =
book exercise.
T/I/A,
Seg M. Fault
the gpf guy
------------------------------
Subject: Re: Good ways to test.
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 03 Jun 2000 15:08:52 -0700
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <mok-
[EMAIL PROTECTED]> wrote:
>
>
>tomstd wrote:
>
>> You are missing the picture.
>>
>> Crypto: I can say a block cipher has 'X' resistance to 'Y'
>> attacks.
>>
>> Medicine: I can say 'X' people get better and 'Y' people get
>> dead.
>>
>> Same thing. In crypto I can say 'DES has a resistance to
linear
>> attacks effectively of O(2^43) work' making it 'strong'. In
>> medicine I can say 99.99% people got better but 0.01% died
>> making it 'a cure'.
>>
>> We didn't know (or now either) if DES could have been broken
>> easily, same for medicine. Those 0.01% may have had kids
before
>> they died that have some wierd genetic disease making 0.01%
>> become much larger.
>>
>> That's why I called it comparative. You wouldn't use FEAL-8
>> over Blowfish would you? Why because given all that we know
>> Blowfish is more secure. Is that definative? Not a shot in
>> hell. But it's better then "What cipher will I use today?".
>
>I wish that there are plenty of people who accept that sort of
>numerical figures of yours. But please don't count on me. I
don't
>buy that.
What the hell are you talking about ? You make no sense anymore
my friend. Virtually all of the stuff you eat or use is 99%
guaranteed not to kill you. There is no 100% in ANYTHING!
>> >2. I know too little about chemistry or phamacology to know
>> what
>> > substance you mentioned is. But apparently you were
>> referring to
>> > the issue of the yet unknown side effects of drugs. Yes,
>> this does
>> > seem to have analogy in crypto, namely the yet unknown
>> > (not yet existing or already existing but secret)
>> techniques of attack.
>> > To that point all what I can say is to repeat my
>> conviction that
>> > anyone applying crypto is responsible to himself for the
>> consequence
>> > of what algorithm he chooses and how the whole security
>> system is
>> > organized and run. No other person can carry that
>> responsibility
>> > for him. He can gather all relevant informations that he
>> can manage
>> > to obtain. But he has to make his own decision
(including
>> such as
>> > to blindly and totally rely on what a certain guru says)
>> and has no
>> > one but himself to blame, if that decision happens to
turn
>> out to
>> > be wrong.
>> >
>>
>> You're right. Companies like Entrust and RSA are *liable* for
>> any damages that occur when people use their tools. So I
would
>> assume they are doing the best they can.
>
>In principle the same comment as above.
>
Believe what you want, but when some RSA component fails in MSIE
and the user sues MS, guess who is next!
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!
------------------------------
From: "TheGPFguy" <[EMAIL PROTECTED]>
Subject: Re: Need "attack time" measurements on a toy cipher... (long)
Date: Sat, 03 Jun 2000 22:12:35 GMT
Joeseph Smith <[EMAIL PROTECTED]> wrote in article =
<TId_4.63$[EMAIL PROTECTED]>...
> This is a Vigenere cipher of the which includes "auto-key"
> (adding C[i-1] to P[i]), which is actually what Vigenere
> originally included in his cipher, though it was dropped
> from the cipher that now has his name
> (C[i] =3D P[i] + k[i mod keylen]).
>=20
> This cipher will take one to two hours to break depending
> on how long the key is, or if the key length is as long as the
> message length, then how many messages are encrypted with
> the same key. Lets assume you have two or more messages
> encrypted with the same key, the steps are:
>=20
[...remainder elided...]
This is exactly what I was looking for!
Thanks so much for the explanation; also for the URL refs you and Tom =
supplied.
(I think my entertainment for tonight will be to mount exactly the =
attack you've described.)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: No-Key Encryption
Date: Sun, 04 Jun 2000 00:43:28 +0200
Greg wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > I suppose there can be situations, though, where authentication is not
> > an issue and there is no active opponent, i.e. no manipulations.
>
> Perhaps I am wrong, but it would seem that if encryption was
> necessary then it is because an enemy could step in and do something
> and that warrants authentication of the recepient.
You are in fact right. One needs to know whether active attacks are
possible, in the affirmative case the scheme in question (even in case
it can be shown to resist passive attacks) is indeed not applicable,
unless it is eventually employed in combination with other
appropriated techniques that could take care of authentication and
integrity.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Good ways to test.
Date: Sun, 04 Jun 2000 00:46:28 +0200
tomstd wrote:
>
> What the hell are you talking about ? You make no sense anymore
> my friend. Virtually all of the stuff you eat or use is 99%
> guaranteed not to kill you. There is no 100% in ANYTHING!
Keep in mind that there is freedom of thought. (I am not in a country
under dictatorship.) You can have your opinion and I can have mine!
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: No-Key Encryption
Date: Sun, 04 Jun 2000 00:43:35 +0200
John Savard schrieb:
> On Sat, 03 Jun 2000 19:19:14 +0200, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Hence the type of operands on both sides of the operator '*' are
> >the same.
>
> Their type, but not necessarily their function. You can't just assume
> things.
I suppose one has to assume that the operator '*' takes different TYPES
of operands on the left and right. Then your argument can go through.
Otherwise, if two data items are of the same data type, then everywhere
the one item is used can (by definition!) be occupied by the other and
there can be no further 'distinctions' (at least this is what is
generally
understood in computer science).
M. K. Shen
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: XTR independent benchmarks
Date: Sat, 3 Jun 2000 15:52:16 -0700
In article <8hb4h1$q3b$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> First of all, thanks for the effort! You certainly prove that doing an XTR
> implementation can be done
> quite quickly (even for a relative outsider); and your quick implemenation
> is even faster than ECC
> over GF(p) already! Doing a fast ECC implementation (including parameter
> generation) is lot more work!
> Could you please tell me why XTR suffers if precomputation is possible?
> Moreover,
> testing that sent group elements are indeed elements of the group (to
> prevent subgroup
> attack; guess this is what you mean) is also required with ECC; just have a
> look at the
> crypto2000 papers (Differential fault attacks on elliptic curve
> cryptosystems).
[Can you please adjust the line wrapping options in your editor? It looks like
your editor is wrapping at more than 80 chars/line and then something else is
wrapping again at less than 80 chars/line.]
I already explained earlier that XTR like LUCDIF cannot take advantage of a
precomputed power table to speed up exponentation of a fixed base. This means
for example precomputing g^(2^n) for n = 5, 10, 15, ... and later computing g^x
as the product of g^(2^n)^(Floor(x/2^n)%32) for n = 0, 5, 10, 15, ...
Is the "Differential fault attacks on elliptic curve cryptosystems" paper
available online? I'm not on the Crypto 2000 program committee so I don't have
access to all the papers yet. Does the paper imply that co-factor
multiplication is no longer sufficient to protect ECC against subgroup attacks?
If so that is a very important piece of news.
> First of all, the hard part of parameter generation in LUCDIF consists of
> generation a
> primenumber p of 512 bits and (and if you're smart a prime number q of about
> 170 bits, such that
> q divides p+1, if you want to be both safe and be able to use subgroups).
> The hard part of
> parameter generation in XTR consists of generation of two prime numbers of
> about 170 bits.
> No way, that LUCDIF parameter is faster! It should (theoretically) be about
> 3^4=81 times slower!
Yes, LUCDIF parameter generation is almost certainly slower (although I didn't
test it), but how often do you generate new paramemters?
> Secondly, if I look at the orginal Asiacrypt94 paper of Smith and Skinner,
> then the elements
> in the group of order p+1 in GF(p^2) are represented as U_n and V_n in GF(p)
> where
> p is of size 512 bits, and:
> V_2n = ((V_n)^2 + D (U_n)^2)/2 en
> U_2n = Un*V*n
>
> V_n+1 = (Vn*U_1 + D*U_n * U_1)/2
> U_n+1 = (Un*V_1 + V_n * U1)/2
>
> So if one uses a repeated squaring technique then:
> - a "squaring" will cost 2 squarings in GF(p) and 1 mult in GF(p);
> - a "mult" will cost 5 mults in GF(p).
> Assuming you use some trick to get rid of the division by 2.
You don't need the U_n, and V_n can be computed with 2 mults in GF(p) per bit
of n. See http://www.eskimo.com/~weidai/lucas.html.
> If you're smart you use a subgroup of order q (divising p+1), of 170 bits
> instead
> of the whole group of size p+1, i.e. of 512 bits size. Note XTR uses such a
> subgroup
> as well.
Actually what I do with LUCDIF is to use p such that (p+1)/2 is also prime, and
then use short exponents during key-pair generation. This saves some of the
trouble of verifying subgroup membership. The same trick doesn't seem to work
with XTR, unfortunately.
> Typically, you will need log(q) "squarings" en log(q)/2 "mults" for a
> exponenation.
> That is: 2log(q) squarings en (1 + 2.5)*log(q) mults in GF(p). Now, as the
> size of
> the basis field in LUCDIF is 3 times larger than in XTR, it reasonable, to
> assume that
> mults and squarings in the LUCDIF basic field is 3^2 = 9 times slower than
> in XTR's basic
> field.
As I explained, in my test XTR 171 was actually doing 256-bit arithmetic. Also
all efficient multiplication implementations show less than quadratic scaling
at the bit lengths we are talking about whether they implement classical or
Karatsuba algorithms. See Michael Scott's paper at
ftp://ftp.compapp.dcu.ie/pub/crypto/timings.doc. So multiplications in the
LUCDIF base field was actually just 3 times slower. XTR requires 4 times more
multiplications which made it slower overall.
> Could you please send me your XTR implementation? We've just put the source
> code
> on www.ecstr.com .
I'll send it through email.
--
cryptopp.com - a free C++ class library of cryptographic schemes
------------------------------
Subject: Re: Good ways to test.
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 03 Jun 2000 15:56:00 -0700
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <mok-
[EMAIL PROTECTED]> wrote:
>
>
>tomstd wrote:
>
>>
>> What the hell are you talking about ? You make no sense
anymore
>> my friend. Virtually all of the stuff you eat or use is 99%
>> guaranteed not to kill you. There is no 100% in ANYTHING!
>
>Keep in mind that there is freedom of thought. (I am not in a
country
>under dictatorship.) You can have your opinion and I can have
mine!
Freedom of thought has nothing todo with this. I am not trying
to force my will on ya, I am telling you the truth.
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!
------------------------------
From: Baruch Even <[EMAIL PROTECTED]>
Subject: Re: Need "attack time" measurements on a toy cipher... (long)
Date: Sat, 03 Jun 2000 22:59:41 +0200
In article <01bfcd82$7497a100$[EMAIL PROTECTED]>, "TheGPFguy"
<[EMAIL PROTECTED]> wrote:
> 5. Iterate across this padded plaintext "P". The ciphertext is "C" =
> and the key is "K".
> a. TempChar = (P[i] + C[i-1]) mod 256
> b. C[i] = (TempChar + K[i]) mod 256
I have been unable to understand the output data that you provided. So
I'll just "cryptanalyze" the cipher itself.
Without any regard the way you generate the key, assuming even that its
a very secure PRNG, this method is completely insecure if you use the key
more than once, notice that byte-wise if I have two ciphertexts encrypted
with the same key I get:
C1[i]-C2[i] = TempChar1[i] - TempChar2[i] = P1[i]-P2[i]+C1[i-1]-C2[i-1]
This is a very weak relation and with enough knowledge about what is
encrypted there I can most probably find the key pretty easily.
A toy algorithm is just that a toy, unless you only want a very short delay
(no more than a few hours) this toy cipher will not work.
Really you'd be better using one of the free cryptography packages out
there that implement a real crypto algorithm. There are quite a few ready
made packages in the net that implement good algorithms and they will
be better and you'll need a short key. Anything from the five finalists in
the AES will work, you have their source for free and they will serve better
than any toy cipher.
Just my opinion.
------------------------------
** 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
******************************
