Cryptography-Digest Digest #323, Volume #12 Tue, 1 Aug 00 04:13:01 EDT
Contents:
Re: Blowfish Implementation ("Martin 'SirDystic' Wolters")
Re: Elliptic Curves encryption (Scott Contini)
Re: Small block ciphers (Terry Ritter)
Re: Small block ciphers (Boris Kazak)
Re: Small block ciphers (Mack)
Re: unbreakable code? Yes ("RecilS")
Re: unbreakable code? Yes (Jim Gillogly)
Re: encrypting folders in Windoze ("r.e.s.")
Re: Proving continued possession of a file ([EMAIL PROTECTED])
Re: Just Curious. Are girls/women interested (Roadkill)
Dimensions of m ("Sergio Arrojo")
Re: Elliptic Curves encryption (Jerry Coffin)
Re: unbreakable code? Yes (Guy Macon)
Re: Reference to a public key technique in NYTimes (Johnny Bravo)
----------------------------------------------------------------------------
From: "Martin 'SirDystic' Wolters" <[EMAIL PROTECTED]>
Subject: Re: Blowfish Implementation
Date: Mon, 31 Jul 2000 02:08:24 +0200
>char *str;
>strcpy(str,"MyStringToEncrypt");
>
>how would this get put into the
>long plaintext in your implementation
I don't know much about Blowfish, but I assume, it's a block Cipher.
This means, the Plaintext is processed in blocks. To encrypt a
Plaintext longer than 32 Bits, divide it into blocks of 32 Bits each,
and process them one by one.
To do this, do something like this:
char *block[5];
int i,j;
for(i=0;i<5;i++)
for(j=0;j<4;j++)
block[i][j]=str[i*4+j];
and then convert it to long.
>and then how to get plaintext back to char
That's easy:
long Plaintext = 11111111101010100101010100000000;
char Pt[4];
Pt[0] = Plaintext>>24;
Pt[1] = Plaintext>>16 & 255;
Pt[2] = Plaintext>>8 & 255;
Pt[3] = Plaintext & 255;
Pt[4] = '\0';
Pt[0] = 11111111
Pt[1] =
1111111110101010
0000000011111111
=============================
0000000010101010
Pt[2] =
111111111010101001010101
000000000000000011111111
===========================================
000000000000000001010101
Pt[3] =
11111111101010100101010100000000
00000000000000000000000011111111
==========================================================
00000000000000000000000000000000
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Elliptic Curves encryption
Date: 1 Aug 2000 00:47:00 GMT
In article <[EMAIL PROTECTED]>,
Roger Schlafly <[EMAIL PROTECTED]> wrote:
>Steve Weis wrote:
>> Which techniques have you had the most improvement with? It sounds like
>> you have mainly worked in GF(2^n). Have you seen an advantage over GF(p)
>> and GF(p^m)?
>
>GF(2^n) has some technical advantages in hardware. However, those
>advantages translate into disadvantages in software.
In software:
I've implemented both GF(2^n) and GF(p) for random curves, and
found them roughly about the same speed. There are certain cases
where GF(2^m) does slightly better and other cases where GF(p)
seems to have advantages. For the GF(p) case I used mostly projective
coordinates since, while GF(2^m) can be implemented efficiently by
using affine coordinates due to a fast inverse algorithm.
(This code was part of BSAFE 4.0, last time I checked. It was not
developed entirely by me - other people made many important contibutions,
but I did the final optimisations with help from Lisa Yin and some
feedback from Bob Silverman).
Certainly one can get speedups by using nonrandom curves (like Koblitz
curves and other subfield curves), or primes of a special form. However,
many experts question the security of ECC in this form.
In terms of comparing ECC to RSA in software for signature verification:
I've always found RSA to be MUCH faster, unless you do a nonoptimal
RSA implementation (such as using a large public exponent, not
implementing the code in assembly) and very dirty ECC code (nonrandom
curves, huge amounts of precomputation - though the latter can at most
double the speed for verification, etc...).
There are many tricks for both ECC (nonrandom curves, unrealistic
amounts of precomputation) and RSA (public exponent 3, modulus of
form p^2*q ) that many people do not trust. It is not uncommon
for people to make comparisons of ECC vs RSA using highly questionable
dirty tricks for one and not for the other. It would be nice if people
would give specific details on their comparisons.
Scott
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Small block ciphers
Date: Tue, 01 Aug 2000 01:59:51 GMT
On 31 Jul 2000 06:29:02 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Mack) wrote:
>[...]
>Your work in this area is noteworthy. Although I don't always
>agree with your ideas, many are unique and well thought out.
Well, thanks! -- I think.
But my point was that the concept of using small block ciphers as
components in a real cipher has *not* been ignored. Many people have
looked at recursive sorts of Feistel things, and otherwise we may need
some sort of balanced mixing.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Small block ciphers
Date: Tue, 01 Aug 2000 02:39:58 GMT
Mack wrote:
> ********************
> a 32 bit block size is subject to a dictionary attack fairly quickly.
> It is only 4GB. My HD is 5 times that. If I only used one
> password in ECB mode it would be readily subject to attack.
>
> 48 bits is only 256 times that. Well within the size of a large system.
>
> Mack
> Remove njunk123 from name to reply by e-mail
=======================
And what about the 8-bit block size? The "dictionary attack" needs only
a table of 256...
The difference is that stream ciphers have Internal State, and so
their security has little to do with the block size. Arrange for a
32-bit
cipher the ability to propagate its Internal State (e.g. a simple
counter)
and see the dramatic increase in security.
BTW, in my opinion this will not be a 32-bit cipher any more...
Best wishes BNK
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Small block ciphers
Date: 01 Aug 2000 04:16:24 GMT
>Mack wrote:
>> ********************
>> a 32 bit block size is subject to a dictionary attack fairly quickly.
>> It is only 4GB. My HD is 5 times that. If I only used one
>> password in ECB mode it would be readily subject to attack.
>>
>> 48 bits is only 256 times that. Well within the size of a large system.
>>
>> Mack
>> Remove njunk123 from name to reply by e-mail
>-----------------------
>And what about the 8-bit block size? The "dictionary attack" needs only
>a table of 256...
> The difference is that stream ciphers have Internal State, and so
>their security has little to do with the block size. Arrange for a
>32-bit
>cipher the ability to propagate its Internal State (e.g. a simple
>counter)
>and see the dramatic increase in security.
> BTW, in my opinion this will not be a 32-bit cipher any more...
>
>Best wishes BNK
>
Going back to the original question about small block ciphers.
Which was has the study of small block ciphers been neglected?
My argument was that it certainly seems so.
Obviously an 8 bit cipher is subject to dictionary attack.
With a small password a cipher is subject to brute force.
But perhaps it is possible to make a cipher that is
provably secure if we use 8 bit blocks. By provably secure
I mean no attacks better than dictionary or brute force.
My current interest is in block ciphers. I am not sure
what relevance the security of stream ciphers has in this.
Certainly adding state increases security, however doing so
it is no longer a block cipher.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "RecilS" <[EMAIL PROTECTED]>
Subject: Re: unbreakable code? Yes
Date: Tue, 1 Aug 2000 00:23:55 -0400
I've just finished a program that I'll be betaing soon. It involves CD
pairs. You give one CD to a friend and keep one. They have real-random
numbers generated from atmospheric noise, and i think you'll agree that
650megs of key is enough to talk for quite some time and even transmit files
using a OTP.
I'll be selling the software and then extra CDPairs for a very cheap price.
the software may be freeware for now, but we'll see.
peace
RecilS
Graham Orme <[EMAIL PROTECTED]> wrote in message
news:u0bh5.16860$[EMAIL PROTECTED]...
> My apologies if this is old, but this seems to be a technique that creates
> an encryption that cannot be decoded. This is because there is a key for
> every permutation of the encrypted message, so one can make it into
anything
> at all.
> This example works on 1000 digit blocks of numbers, which might be for
> example ascii. John and Mary wish to exchange messages. First, John sends
by
> some secure method a (for example) 10,000 digit number perhaps by meeting
or
> by courier. Mary now has the 10,000 digit number, called A. John then
> composes a password of 10,000 digits called B and subtracts A from it and
> send this to Mary. Mary receives B-A and because she knows A now knows B
but
> no eavesdropper can know B or A which can be any possible 10,000 digit
> numbers. Mary gets another 10,000 digit number called C perhaps randomly
and
> subtracts B from it, and sends C-B to John. Of course an eavesdropper
cannot
> know C or B from the number sent. They continue in this way until they
have
> enough secure passwords. Note that if someone learned A they could find
out
> the rest, so the security hinges on A being secure.
> John and Mary now want to send 1000 digit numbers to each other, which
> might be ascii messages or anything else. John's first message is called
Z.
> John takes the first 1000 digits of B and subtracts it from the message Z,
> then takes the next 1000 digits of B and add it to Z, then the next 1000
> digits and subtracts it from Z and so on until the 10,000 digits of B are
> used. John sends this message and Mary decodes it since she knows B. Mary
> composes a message Y and encodes it with the password C as before which
John
> knows how to decode. They can continue like this forever wthout any
> eavesdropper being able to decipher any message, since each possible 1000
> digit number can be gotten from a corresponding 10,000 digit number. One
> therefore cannot narrow down what the 1000 digit message to any less than
> all the possible numbers up to 1000 digits long. The password could be
less
> than 10,000 digits and still be secure, and might even be ok at 1,000
> digits.
> Any flaws in this?
>
>
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: unbreakable code? Yes
Date: Tue, 01 Aug 2000 05:29:43 +0000
RecilS wrote:
>
> I've just finished a program that I'll be betaing soon. It involves CD
> pairs. You give one CD to a friend and keep one. They have real-random
> numbers generated from atmospheric noise, and i think you'll agree that
> 650megs of key is enough to talk for quite some time and even transmit files
> using a OTP.
>
> I'll be selling the software and then extra CDPairs for a very cheap price.
> the software may be freeware for now, but we'll see.
And you don't keep a copy of the CD pairs you send out, right?
This is the "trust me" encryption system?
--
Jim Gillogly
Hevensday, 9 Wedmath S.R. 2000, 05:28
12.19.7.7.13, 1 Ben 16 Xul, Ninth Lord of Night
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: encrypting folders in Windoze
Date: Mon, 31 Jul 2000 22:42:44 -0700
In this vein, does anyone here have experience with Cryptext?
It appears to be SHA1/RC4-based freeware.
See http://www.pcug.org.au/~njpayne
--r.e.s.
<[EMAIL PROTECTED]> wrote ...
| Can anyone share how they encrypt folders in Windoze? Winzip? I
| basically just want to be able to lock folders and their contents
| from snooping eyes.
|
| Thanks, and my apologies if this is too basic.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Proving continued possession of a file
Date: Tue, 01 Aug 2000 05:43:23 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > x_i = ith block of 1000 bits within the file
> > y_i = concatenate(i, x_i)
> > M = y_1 * y_2 * y_3 * ...
> >
> > Now M isn't the file itself any more, but a simple function
> > of it.
>
> ... but Bob (if I can get it right this time :-) only has to store M,
> not the message.
M is slightly larger than the original message, so Bob doesn't
gain anything by doing that.
Bob never has to actually calculate or store M, since he can
exponentiate with the y_i instead of with M. This approach
doesn't save computation time. The single large exponentiation
is replaced with a set of small exponentiations that take about
the same total time. I think this is interesting, but it may
not be useful.
LCB
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: 1 Aug 2000 06:11:59 -0000
From: Roadkill <[EMAIL PROTECTED]>
Subject: Re: Just Curious. Are girls/women interested
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
>
> Paul Rubin wrote:
>
> > Off the top of my head, Jennifer Seberry, Shafi Goldwasser, Cynthia
> > Dwork, Hilary Orman, and yes, Dorothy Denning all come to mind.
> > All of them (usually) have the good sense not to post here though.
>
> Your last sentence is very noteworthy and should provide food for
> reflections.
They could post under a cryptographicaly strong pseudonym, sign their
posts and later show that they posses the secret key of that nym. If
they want to. For instance, can you tell I am a girl cryptographer? No?
So can't I ;-O But seriously, you can build quite a strong reputation
using a nym. Just take a look at Stray Cat in a.p.a-s and a.s.p. He's
great! Even though he posts with X-No-Archive: yes and doesn't sign his
helpful posts.
Keep hoping and maybe this group will have female input,
Roadkill
- --
"If you're so special, why aren't you dead" - Kim Deal
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of redneck.gacracker.org.
Date: Tue Aug 1 06:11:56 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3a
Charset: noconv
iQCVAwUBOYZqLpLupyyiz83tAQHENAP/VR7xmITA60+qccb+3YevK+3Dtz2IY0W9
ZF/sOnuLQll5BCW7zES+RxoEtKv6I4Um9xCtOHZv8sOsvZx3N3f0DkgnWZ5SV2cA
eS0mxbfFFHmlH4Tn7OsqhEVKepbzL2hIVOWOYYJG1n6xJ3VTMtG6p33HAYOtLt1m
puo0+D+9V2o=
=HIs0
=====END PGP SIGNATURE=====
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: Dimensions of m
Date: Tue, 1 Aug 2000 09:40:06 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
Why do I find always the same dimensions for m when implementing Elliptic
Curves appropiate for Cryptography. That is, most softwares offer curves
with m values (24,30,33,39,40...), are these numbers for any reason better?.
Why do we want to describe the m with two different factors (prime and not
prime), why don t just use directly a prime number?
does it, maybe, make the algorithms easier and faster to run, if then, why?
Thanks
Sergio Arrojo
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Tue, 1 Aug 2000 01:39:09 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> -- mostly designed by "publishing academics," by the way -- are not
> designed for proof. Most are not scalable, which prevents us from
> realizing the design in a tiny cipher which could be deeply examined
> experimentally.
Okay, so if I understand you correctly, you're agreeing that most of
the symmetric algorithms most people have available have nothing even
vaguely similar to proofs attached to them. As I understand things,
you're further stating that the few that have some sorts of proofs
attached to them can't be scaled up to the point of being really
useful. Is that correct?
> I'm sorry if I mischaracterized your thoughts, but the best way to
> verify understanding is to describe what has been said in different
> words. On the other hand, I fail to see where my characterization
> differed from your words, which are right above:
>
> * You set up one case where you think strength "MIGHT" exist.
>
> * Then you address the other case where you are absolutely sure that
> the current strength does *not* exist.
Say what? Are you attempting to say something about a proof of
strength not currently existing, perhaps? For the moment I'll assume
that's what you meant to say, but if not you'll have to explain what
you mean here.
> * Then I characterize your words as a preference for a particular form
> of cryptography based on your (insupportable) belief of strength.
That, of course, is the crux of the problem. First of all, when this
started I said that some hypothetical person might trust PK
algorithms more than s/he did symmetric algorithms. I then went on
to note some of the reasoning that might lead this hypothetical
person to such a belief, but never said (nor am I now saying) that I
think the reasoning is sufficient to draw this conclusion, only that
I can see a line of reasoning by which somebody might feel justifed
in drawing the conclusion.
> That would seem to be factual analysis, not mischaracterization. With
> exactly which part do you disagree?
Most of it. I can see reasoning by which somebody could draw a
conclusion. You've apparently taken that as an indication that _I_
have drawn that conclusion. You've apparently decided that anything
that isn't proven to your satisfaction MUST be assumed to be
completely false. Again, I can see situations in which something
looks like it's probably provable, but nobody's gotten around to
proving it yet.
In the last regard, keep in mind that (to give but one example)
regardless of what Certicom likes to point out, that serious study
specifically of ECC is _quite_ recent. They like to point out its
long history to give an indication that it's not likely to be broken.
I look at things from the opposite direction: its short history of
serious research is likely part of the reason for lack of proof.
Developing a proof often takes a lot of time and effort. Quite a few
things that are probably provable haven't been proven yet for the
simple reason that nobody's had a chance to even study them seriously
yet. In a lot of cases, we've only known for a relatively short time
what things it would even be interesting to prove.
> The more casual meaning of "proof" is "correct mathematical
> manipulation." This is the action of proof without the result. It
> means: "Given these assumptions, what would be the consequences?"
> But manipulation -- even correct manipulation -- has nothing to do
> with fact. A better and classic word to describe this situation is
> "theory," not "proof."
I don't particularly care about the terminology you use, though at
least as I read things, you've defined "proof" in a way that nothing
can possibly be proven. Ultimately, any "proof" must always be based
on assumptions -- it's a tautology of logic that you can't prove the
laws of logic.
In any case, if you prefer to change the terminology, so be it. PK
algorithms have theories of strength, but lack proofs. Most
practical symmetric algorithms lack both proofs AND theories of
strength.
> We can tell that cryptography is not a science because we have
> incomplete proofs widely being taken as something they clearly are
> not: an "almost" proof of result.
By this standard, biology, physics, chemistry, etc., aren't sciences
either. Nobody's absolutely proven the general theory of relativity,
but most current physicists take it nearly for granted as a fact. By
your standard of proof, the theory of evolution is probably
completely unprovable, but nearly every biologist accepts it without
question as well. In chemistry we commonly make assumptions about
the number of electrons that can live in a given shell, and that
theory seems to fit pretty darned well with how chemicals combine.
Despite this, we know we can't directly observe electrons in their
native habitat, so to speak.
IOW, "science", by your definition has never and probably will never
exist! Humpty-Dumpty would be proud of you...
> When something we think is obviously believable and acceptable cannot
> be proven, we are almost compelled to believe that the assumptions are
> not nearly so benign and trivial as they at first may appear. The
> very fact they exist as statements which are believable yet cannot be
> proven as fact means they are logic wolves in sheep's clothing. This
> should be very disturbing to everyone.
Yup...and since brilliant mathematicians studied Fermat's last
theorem for centuries, and none of them proved it, we should conclude
that nobody ever can prove it; either that or maybe some things are
true and provable, but just haven't been proven yet.
> No, you have not seen strength proofs for PK algorithms. You may have
> seen assertions, based on questionable assumptions. Apparently you
> have accepted this work-in-progress as a final result.
Once again, you seem to be attributing to me things I've never
thought or said. I haven't accepted any of this as a final result. I
see, however, work in progress on one side of things, but on the
other side not only lack of proof, but not even work in progress, and
in most cases not even an attempt at defining where work would start.
To use an analogy: proofs of strength of PK algorithms at roughly the
point of a building that's about half built. It's not ready for
occupation yet, but you can easily see the basic structure of a
building, and if you talk to the right people, you can look a the
blueprints that show what needs to be added where and so on.
Proofs of strength of most symmetric algorithms are at something
closer to the level of an six year old boy saying "I'm gonna build
skyscrapers when I grow up."
You seem to be saying that since I acknowledge the fact that a
foundation and basic structure has been built that I'm claiming the
building is finished. That's obviously not the case. I can even
believe that unforseen complications might prevent the half-finished
building from ever being completed. It's barely possible that it'll
still be standing there half-finished when the six-year-old grows up,
and he'll tear it down and actually finish a real building in that
place.
Now, I'm not very likely to invest in the building right away, but I
can certainly see it as a more sensible option than giving the money
to the six-year-old's parents so I'll get in on the ground floor
(pardon the pun) when he builds his first skyscraper...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: unbreakable code? Yes
Date: 01 Aug 2000 03:48:41 EDT
Jim Gillogly wrote:
>
>
>RecilS wrote:
>>
>> I've just finished a program that I'll be betaing soon. It involves CD
>> pairs. You give one CD to a friend and keep one. They have real-random
>> numbers generated from atmospheric noise, and i think you'll agree that
>> 650megs of key is enough to talk for quite some time and even transmit
files
>> using a OTP.
>>
>> I'll be selling the software and then extra CDPairs for a very cheap
price.
>> the software may be freeware for now, but we'll see.
>
>And you don't keep a copy of the CD pairs you send out, right?
>This is the "trust me" encryption system?
If a determined attacker threatens your life, family, etc. if you don't
make three copies and give one to him, and also offers a large fee if
you do, you will die rather than comply, right?
There is more than one way to "break" a method of secure message
transmission. It makes little sense to put a case hardened deadbolt
of a safe made cardboard.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Reference to a public key technique in NYTimes
Date: Tue, 01 Aug 2000 03:45:55 -0400
On Mon, 31 Jul 2000 17:35:10 +0100, Gordon Walker <[EMAIL PROTECTED]>
wrote:
>> Play music, record music as it gets sent to speakers. The software
>>needed for this is already around, I've used it to record a broadcast
>>channel playing through WinAmp.
>
>But it's not a direct digital copy, you're adding a trip out through
>the A/D converter and back in through the D/A.
Not so, I didn't mean to put a microphone next to the speaker and
record it. You record the signal after decryption on it's way to the
sound card. Entirely internal to the computer, no degradation at all.
--
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
------------------------------
** 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
******************************
