Cryptography-Digest Digest #498, Volume #14       Sat, 2 Jun 01 19:13:01 EDT

Contents:
  Re: Luby-Rackoff Theorems? (Nicol So)
  Echelon electronic eavesdropping network (Nemo psj)
  BBS implementation ([EMAIL PROTECTED])
  Re: Cookie encryption (Chenghuai Lu)
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
(sisi jojo)
  Re: Small (not fast) RIPEMD-160 (Ian Stirling)
  Re: How many chains can you use? [Flamewar] ("Thomas J. Boschloo")
  Re: BBS implementation ("Tom St Denis")
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
("Tom St Denis")
  Re: Cookie encryption (Paul Rubin)
  Re: Luby-Rackoff Theorems? (David Wagner)
  Re: Cookie encryption (those who know me have no need of my name)
  Re: Cookie encryption (those who know me have no need of my name)
  Re: Question about credit card number ("Jeffrey Walton")
  Re: Question about credit card number ("Tom St Denis")

----------------------------------------------------------------------------

From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Luby-Rackoff Theorems?
Date: Sat, 02 Jun 2001 15:27:16 -0400
Reply-To: see.signature

David Wagner wrote:
> 
> Nicol So  wrote:
> >> If I get this correctly isn't [the Luby-Rackoff] theorem recursive?
> >
> >Yes, you can apply the result recursively.
> 
> But beware: The guaranteed security level drops dramatically
> each time you apply it.  Remember, these security theorems
> say "the construction is secure against adversaries using at
> most q queries"; and the q will go down by the square root
> for each extra level of recursion.

I could be wrong, but I don't think the Luby-Rackoff results are of that
form. I think they were able to come up with an upper bound on the
distinguishing probability of any polynomial-size circuit, based on the
number of times the oracle is consulted. The upper bound is a
"negligible" function in the security parameter. I don't think there's a
threshold on the # of queries beyond which the security (distinguishing
probability) drops (increases) dramatically.

The phenomenon you pointed out is one of the "nuances" I was referring
to in my previous message. Often times constructions in
complexity-theoretic security proofs can be applied
repeatedly/recursively a polynomial # of times without changing the
asymptotic results. But that doesn't mean it doesn't matter when the
construction is used in practice.

"In theory, there's no difference between theory and practice. In
practice, there is." (I don't know who originally said it, but I think
it's very true.)

-- 
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.

------------------------------

From: [EMAIL PROTECTED] (Nemo psj)
Date: 02 Jun 2001 19:34:55 GMT
Subject: Echelon electronic eavesdropping network

There was supposedly a new report made in the UK.  Does anyone here know were I
can find it?

------------------------------

From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: BBS implementation
Date: Sat, 02 Jun 2001 12:53:43 -0700

Where can I find some info on practical BBS implementation?

Joe



------------------------------

From: Chenghuai Lu <[EMAIL PROTECTED]>
Subject: Re: Cookie encryption
Date: Sat, 02 Jun 2001 15:59:09 -0400

those who know me have no need of my name wrote:
> 
> a) just because a specification says that something should not be
>    done, or even may not be done, does not actually prevent the web
>    site from doing it.

The right way to send those sensitive data is to use ssl protocol.
However, most of the websites don't stick to it. Why? Because ssl has
big overhead, or just because the programmers lack of basic idea of
security?
 
-- 
                                        
                        -Chenghuai Lu ([EMAIL PROTECTED])

------------------------------

From: [EMAIL PROTECTED] (sisi jojo)
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large 
Primes
Date: 2 Jun 2001 13:19:59 -0700

[EMAIL PROTECTED] (Merc42) wrote in message 
news:<[EMAIL PROTECTED]>...
> I am semi-new to cryptography and am currently in the middle of a
> school project based on it.  I was wondering if anybody could give me
> any advice in helping me with my project in which i hope to compare
> the mathematical differences in using discrete logs, the knapsack
> (super increasing and non), and factoring large primes as a basis of
> cryptographic security.  I was wondering if anybody knows any good
> books on complexity theory that could help me or any other help would
> be greatly appreciated.
> 
> -Thanx
> 
> 
> ...and just maybe im to blame for all ive heard...

Cryptography isn't that hard. Don't listen to the discouragement
on this newsgroup. Breaking some real codes may be hard. But nobody
expects you to break codes as a school project. 

You may be looking for a 2nd or 3rd year college textbook on complexity 
theory or algorithm. But actually all you need to know is one definition:
the big-oh notation.   

Here's a dilemma for everyone to think about.
If you learn the number field sieve, you will not be able to factor.
Therefore, if you want to factor, you should not learn the number field sieve.

Google finally has posting feature. Hurray!

--Sisi

------------------------------

From: Ian Stirling <[EMAIL PROTECTED]>
Subject: Re: Small (not fast) RIPEMD-160
Date: Sat, 02 Jun 2001 20:44:00 GMT

Mark Wooding <[EMAIL PROTECTED]> wrote:
>Ian Stirling <[EMAIL PROTECTED]> wrote:

>> Impressive, though the stripped .o file is >2K, with all the compilers
>> I have. (egcs and gcc).
<snip>
>> I'm pretty sure I can get it a little smaller than this, as I have a 
>> cunning plan...

>Good luck.  I'd be interested to see the finished result.

Ok, size says 752, and it's about twice as fast. A third of the speed
of the reference implementation. And, even better, it still passes the
tests.

(With a 160 byte static array)

I think I can get it down a little more.
The resultant binary (with a little stripping of .note/.comment) is 
down to 3476 bytes.

Could do with a little more, so I'm still polishing it as inspiration
arrives.

Deeply ugly code, as it's been hacked rather a lot.

-- 
http://inquisitor.i.am/    |  mailto:[EMAIL PROTECTED] |             Ian Stirling.
===========================+=========================+==========================
Lord, grant me the serenity to accept that I cannot change, the
courage to change what I can, and the wisdom to hide the bodies
of those I had to kill because they pissed me off.                  -  Random

------------------------------

From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.security.scramdisk
Subject: Re: How many chains can you use? [Flamewar]
Date: Sat, 02 Jun 2001 22:33:48 +0200

(Followup set, feel free to override as I read all three groups)

=====BEGIN PGP SIGNED MESSAGE=====

Frog2 wrote:

> Please, don't reply to "Thomas J. Boschloo"
> It gives the false impression that "Thomas J. Boschloo" *sometimes* says
> something accurate.

I never say something accurate. Q.E.D.

> Most contributors here made the choice *never* to answer Boschloo.

Quicksilver might not respond to me frequently, but that doesn't mean he
has kill-filled me or doesn't apreaciate my posts. Stray Cat answered me
just a few weeks ago. <thanks Stray, I need that sometimes>. Stray Cat
has been arround this group longer than I can remember and certainly
outlives me in this group. I know he does dislike the kind of troll you
are (or were when you flooded this group with thousands of messages a
day).

> Picking on all his false statements and correct them would be too much of a
> waste of time.
> IIRC, last autumn, Frog-Admin went so far as to issue what he called a
> "blanket denial" for all future posts by Boschloo.

He did flame me at one time. But a "blanket denial for all future
posts"?? Can you look up that post for me again on Google or something?
Something like
<http://groups.google.com/groups?rnum=2&ic=1&selm=7b9di3%24ov8%241%40nnrp1.dejanews.com>
will do the trick possibly. (You can probably even skip the rnum, but I
am not sure anymore).

> To newbies:
>  Boschloo is *not* a remop

True, I haven't got the resources or knowledge to run a secure remailer.
Not many remops do IMO, but that does not make their service any less
valuable to me. It is the thought that counts here.

>  Boschloo is *not* a seasoned remailer use

True, I mostly post directly from my sonera account.

>    he is not even a remailer user

Not true. But there is not much point in posting a signed message
through remailers just to prove I am a remailer user.

>  Boschloo is *not* a seasoned m2news user

Maybe, but there is not much to using m2n servers.

>    he is not even a m2news user

What is a m2n user anyway? Does using the 'Post' directive count as
this?

>  Boschloo is *not* a seasoned PGP/crypto user

I am pretty seasoned in PGP in my own opinion. I just haven't figured
out the theory behind DH/AES yet :-)

>    he made such blunders as
>     -providing onsolete keys

At request and with thank you replies as a result.

>     -failing to detect a fake PGP signature

I never said I could properly wrap FA's message to make it verify. You
can hardly expect me to download every signature ever made by FA to see
if it was copied from another message.

>     -not understanding what "time zone" was

Do I not understand what a TZ is? Can you specify the post at which I
did not? FYI, I have been working with Zulu time since I was a telexist
for the dutch army in 1992-1993. If I would not know what a time zone
was, I would not be able to function as a telexist 'national sector' as
I did. I even have a diploma stating that I am which I could have
somebody scan in for me and put on my homepage (just for you).

> On nearly evey NG, you find that kind of character:
>   a lonesome dropout, eager to find some "glory" on Usenet

Thank you, I do think I am very glorious on usenet now and then :-) That
is what keeps me here. Do you feel glorious also? Can you give an
example?

> Because nor his intelligence nor his knowledge will bring that glory,
> he compensates by dozens of stupid post, silly flame wars,

Your words. I one group my anti-troll behaviour was called a 'paradigm
of dealing with trolls'. It is not stored at deja, but I have a copy in
my inbox :-) It is times like those that make me a very happy person.

> and pretense of being on a farting acquaintance with reputable contributors
> that dubious reputation fulfills his need for recognition

FYI, take a look at my homepage and see a file that Sam Simpson has
hosted for me at the scramdisk.clara.net server. Do you have a file
hosted at Sam and Shauns site or are you just the real lamer of the two
of us here?

> On apas, his name is "Boschloo"

So it is elsewhere. From your own agruments I understand that you claim
that I am incapable of using nyms. Q.E.D.

> Killfile him
> The only thing you will ever learn from him is
> how far somebody is willing to go to get even the most dubious reputation

Controversial because I like to lick trolls like you. Not 'dubious'.
Just is case, it got your attention and stopped you from flooding
innocent newsgroups.

Happy regards,
Thomas

(BTW You forgot to mention your usual 'suicide hoax' about me)

=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: My homepage <http://home.soneraplaza.nl/mw/prive/boschloo>

iQB5AwUBOxk+/QEP2l8iXKAJAQFUsQMgk1AnIV/G3q3TwC8mpQbNHtil6R/oDxVc
ZC5fd/R1ptktPeYwhH5IzrMXhkPz0flYRgbTNiq3Y568RNtaHHTPrpxam/W+2G50
wJJ3d4R8Gq2UW9Amjj60gMzQhDZnLAl2DFEM4w==
=c0Wo
=====END PGP SIGNATURE=====
-- 
Les Claypool: "Do'nt do as they say. Just say as they do. No flavor's
quite so bitter as the taste of one's own shoe".



------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: BBS implementation
Date: Sat, 02 Jun 2001 21:17:41 GMT


<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Where can I find some info on practical BBS implementation?

Um, square an integer modulo a composite blum integer repeatedly and output
the log log n lower bits

What else do you want?

Tom



------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large 
Primes
Date: Sat, 02 Jun 2001 21:21:55 GMT


"sisi jojo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Merc42) wrote in message
news:<[EMAIL PROTECTED]>...
> > I am semi-new to cryptography and am currently in the middle of a
> > school project based on it.  I was wondering if anybody could give me
> > any advice in helping me with my project in which i hope to compare
> > the mathematical differences in using discrete logs, the knapsack
> > (super increasing and non), and factoring large primes as a basis of
> > cryptographic security.  I was wondering if anybody knows any good
> > books on complexity theory that could help me or any other help would
> > be greatly appreciated.
> >
> > -Thanx
> >
> >
> > ...and just maybe im to blame for all ive heard...
>
> Cryptography isn't that hard. Don't listen to the discouragement
> on this newsgroup. Breaking some real codes may be hard. But nobody
> expects you to break codes as a school project.
>
> You may be looking for a 2nd or 3rd year college textbook on complexity
> theory or algorithm. But actually all you need to know is one definition:
> the big-oh notation.
>
> Here's a dilemma for everyone to think about.
> If you learn the number field sieve, you will not be able to factor.
> Therefore, if you want to factor, you should not learn the number field
sieve.

Um as far as I know if you learn the NFS and some basic number theory you
should be able to factor quite easily.  I know this is the case for QS (ok
let's assume the size of the composite is trivial_

Tom



------------------------------

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Cookie encryption
Date: 02 Jun 2001 14:24:57 -0700

Chenghuai Lu <[EMAIL PROTECTED]> writes:
> The right way to send those sensitive data is to use ssl protocol.
> However, most of the websites don't stick to it. Why? Because ssl has
> big overhead, or just because the programmers lack of basic idea of
> security?

One typical reason for encrypting cookies is to prevent the *user*
from reading or messing with their contents.  SSL won't help with that.

SSL slows down browsing because for obvious security reasons, browsers
won't normally cache data that's been sent by SSL.  So all those
little gifs etc. commonly found on websites get sent over and over
again instead of being cached.  That's why the secure order forms of
retail sites usually have fewer graphics than the rest of the site.

A few years ago the cryptographic operations of SSL were cpu-intensive
enough that doing a lot of SSL loaded down the server.  But computers
are so fast now that the cryptography overhead isn't much of an issue
except for the largest sites.

------------------------------

From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Luby-Rackoff Theorems?
Date: Sat, 2 Jun 2001 21:45:59 +0000 (UTC)

Nicol So  wrote:
>I could be wrong, but I don't think the Luby-Rackoff results are of that
>form.

They are.  If you want to build a cipher with a n-bit block, Luby-Rackoff
only guarantees security up to q ~ min(2^{n/4},q') chosen texts, assuming
that the Feistel function is secure with up to q' chosen texts.  This bound
is tight: There are attacks that can distinguish a Luby-Rackoff cipher from
an ideal cipher with O(2^{n/4}) texts, for example.

Let's say you want to use Luby-Rackoff twice to build a n-bit block cipher.
You're going to use Luby-Rackoff to build the n/2-bit Feistel function,
and so this Feistel function will only be secure up to q' ~ 2^{n/8} texts.
As a consequence, the entire cipher will only be guaranteed secure up to
q ~ 2^{n/8} texts as well.

For instance, suppose you want to build a 128-bit block cipher.  With
plain Luby-Rackoff, you can build one that is secure for up to 2^32 texts.
With two levels of recursion, it is secure only up to 2^16 texts.  And so on.

Hence my conclusion: you can use Luby-Rackoff recursively, but the security
guarantees get progressively weaker each time you do (assuming the block
size is held constant).

------------------------------

From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Cookie encryption
Date: Sat, 02 Jun 2001 22:11:25 -0000

<[EMAIL PROTECTED]> divulged:

>SSL slows down browsing because for obvious security reasons, browsers
>won't normally cache data that's been sent by SSL.  

hold on to your toes ... ie does, by default.

-- 
okay, have a sig then

------------------------------

From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Cookie encryption
Date: Sat, 02 Jun 2001 22:22:48 -0000

<[EMAIL PROTECTED]> divulged:
>those who know me have no need of my name wrote:
>> 
>> a) just because a specification says that something should not be
>>    done, or even may not be done, does not actually prevent the web
>>    site from doing it.
>
>The right way to send those sensitive data is to use ssl protocol.

yes, but that doesn't make the cookie safe forever.  if the cookie is
persistent it will live on the hard disk, and if it isn't strong enough
it might be usable in a future session, perhaps slightly altered, by
someone able to snarf the cookie from your system.

further, just because a cookie is marked "ssl only" doesn't prevent a
filesystem attack from yielding the data, since the browser (the only
thing that looks at the cookie type anyway) isn't involved.  and if the
browser is involved some don't pay any attention to that mark, e.g., ie
prior to a certain patch, and will provide it outside of an ssl session.

>However, most of the websites don't stick to it. Why? Because ssl has
>big overhead, or just because the programmers lack of basic idea of
>security?

yes and no.

some sites have idiots running or programming them.  buyer beware is the
only thing that might help with that, although at some point their fraud
level is likely to become too high for them to retain their merchant
account.

some sites rationalize that sending you graphics shouldn't involve an
ssl operation, however most sites won't consider doing that since most
browsers will remove the "secure" indicator and the company doesn't want
that -- even advertising servers, e.g., doubleclick.net, will serve ssl
content just to help their customer keep that indicator displayed.
(an indicator that is almost entirely meaningless.)

-- 
okay, have a sig then

------------------------------

Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: Question about credit card number
Date: Sat, 2 Jun 2001 18:45:01 -0400

Tom,

Do you argue that one cannot compare complexities of symmetric and
asymmetric cryptosystems?

I understand the systems are fundamentally different.  That was not my
point.  I apologize if I was vague.

Jeff


"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:r73S6.8370$[EMAIL PROTECTED]...
:
: "Jeffrey Walton" <[EMAIL PROTECTED]> wrote in message
: news:3b186060$0$[EMAIL PROTECTED]...
: > : What the heck does that mean?  asymmetric ciphers solve different
: > problems
: > : then symmetric ones.
: >
: > I knew I was going to get flamed for that.
: >
: > See Schneier, Applied Cryptography, Chapter 7, Section 3 on page 165
and
: > the accompanying table 7.9.
:
: And Schneier should be ashamed of himself too.  The comparaison is
: meaningless.
:
: Tom
:
:



------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Question about credit card number
Date: Sat, 02 Jun 2001 22:48:33 GMT


"Jeffrey Walton" <[EMAIL PROTECTED]> wrote in message
news:3b196b97$0$[EMAIL PROTECTED]...
> Tom,
>
> Do you argue that one cannot compare complexities of symmetric and
> asymmetric cryptosystems?
>
> I understand the systems are fundamentally different.  That was not my
> point.  I apologize if I was vague.

The problem is that the compaison do not make sense.  Even comparing keys
from different symmetric ciphers is stupid.  A 56-bit Blowfish key provides
more security (in theory) than a 56-bit DES key.  (hint think linear attack)

Comparing RSA to Rijndael is a ignorant thing todo.  Yes, there are
suggested key lengths for both, but they are not equivalent.

Tom



------------------------------


** 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
******************************

Reply via email to