Cryptography-Digest Digest #919, Volume #11 Fri, 2 Jun 00 12:13:01 EDT
Contents:
Re: Contest rule proposal (tomstd)
Re: Powers of s-boxes and other functions (Jim Steuert)
Re: otp breaktrough !!!!!!!!!!!!! ("Trevor L. Jackson, III")
Re: XTR (was: any public-key algorithm) ("Eric Verheul")
Re: XTR (was: any public-key algorithm) ("Eric Verheul")
Re: Contest rule proposal (Mark Wooding)
Re: Contest rule proposal (tomstd)
Re: Weak Keys in TC3 (tomstd)
Re: UDP Cotse (Roger Williams)
Re: Free Crypto-Lib for VB? ("norman")
Re: Contest rule proposal (Terry Ritter)
Re: Contest rule proposal (Terry Ritter)
Re: Contest rule proposal (Mark Wooding)
How RSA SecurID tokens work? (tomstd)
http://www.infraworks.com product (Thomas Kellar)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (Adrian Kennard)
Solovay-Strassen primality test (Marek Futrega)
Re: RSA/PK Question (You should do your homework first, you know this conversation
can go on for longer than breaking your overly small 768-bit keys) ("Joseph Ashwood")
Re: Contest rule proposal (Andru Luvisi)
Re: Weak Keys in TC3 ("Scott Fluhrer")
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (Eric Lee
Green)
----------------------------------------------------------------------------
Subject: Re: Contest rule proposal
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 04:30:14 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Mark Wooding) wrote:
>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>> Sorry for asking a dumb question. If a patent-holder gives a
world-
>> wide royaltyfree license, why should he have spent money to
obtain
>> the patent in the first place? Because it is simply fun and
fashion
>> nowadays to be patent-holders, perhaps? Thanks.
>
>The simple answer: that's not my problem.
>
>The more complicated answer: it only has to be the particular
algorithm
>which is free for DFSG-freeness; you can retain patent rights on
>variants. Consider, for example, that the CAST design
procedure is
>patented, whereas CAST-128 and CAST-256 are both licensed
worldwide
>royalty-free and have been adopted as RFCs.
Similarly for IDKA (minus for-profit usage). Of course if
anyone patents their sci.crypt submission they have problems.
BTW ever wonder if the CAST sboxes are magically cool, why they
use rotations/etc in the round function? Me thinks they are
just being wierd and obtuse. They could simplify the whole
thing and boast 'we have a simple algorithm'.
My 2c.
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: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: Powers of s-boxes and other functions
Date: Fri, 02 Jun 2000 07:44:38 -0400
Reply-To: Jim, Steuert
Hi Tom,
I used s-boxes in the title as a simple means of example, not to imply that
permutation polys should be used for sboxes.
It is trivially easy to compose two tabular s-boxes to form a third sbox.
Then
by starting with a "root" s-box s(x), we can build s(^2(x)) = s(s(x)) simply
by chasing the links for each of the 2^m rows of the sbox, to form the
s(^2(x)). Likewise we can form s(^4(x)), s(^8(x)), etc. And then we
composing the s-boxes corresponding to the binary powers in the
iteration count (i.e s(^106) = s(^64(s(^32(s^8(s^(2)))))) ). This is the
same technique. This gives us the ability to form some huge power of
any s-box permutation.
For permutation polynomials, I just do substitution of variables,
and then some reduction formulas like ((2^w)/4)*x^4 == ((2^w)/4)*x^2 mod 2^w
and others like ((2^w)/16)*x^8 == ((2^w)/16)*(2x^6-x^4) mod 2^w
to reduce the size of the poly. For example, mod 128,
r(x) = 1 + 7x + 2x^2
r(^4(x)) = 44 + 105x + 48x^3 + 16x^4
r(^8(x)) = 56 + 17x + 32x^2 + 32x^3
and so on. mod 128
My hope is that the technique of substitution ala algebra can be applied
to more complicated functions.
-Jim Steuert
tomstd wrote:
> In article <[EMAIL PROTECTED]>, Jim Steuert
> <[EMAIL PROTECTED]> wrote:
> >Hi David,
> >
> > Thanks for your papers. I looked at them briefly. I will
> study them,
> >but I accept your results.
> >
> > I have been able compose permutation polynomials,
> >and thus form powers.of a permutation (which must be
> permutations).
> >Note that we are iterating the whole function description. Only
> after we
> >iterate do we plug in a value. For powers of a permutation,
> the plugged-in
> >values can't collide. It all depends on what you consider the
> inputs of the
> >function.There are in fact two inputs: f(iteration count,root-
> value). I'm
> >not
> >sure that collisions of the "count" would be a problem in some
> applications.
> >Plus,
> >I think we can make the probability of such collisions
> vanishingly small
> >with some functions (I haven't shown this)
> >
> >My hope is that this we can find a large variety of functions
> via symbolic
> >algebraic methods. Several modern crypto functions have
> algebraic
> >description which may be useful for designing classes of these
> functions.
>
> Words of caution. Permutation polynomials form terrible sboxes.
>
> 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!
------------------------------
Date: Fri, 02 Jun 2000 08:01:48 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: otp breaktrough !!!!!!!!!!!!!
Looks like another satisfied Visual Studio user gets "Hello, world!" to
compile.
analyser wrote:
> analyser did it again !!!!!!!!!!!!
>
> it works......
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: XTR (was: any public-key algorithm)
Date: Fri, 2 Jun 2000 13:55:05 +0200
> Have you thought about generalizing LUC/XTR to even higher extension
fields? It
> sure seems like it should be possible, even if XTR turns out to be the
sweet
> spot.
Read the Asiacrypt 99 paper, see www.ecstr.com.
> On a different note, what exactly is the "generic software" (p.15) that
you
> used to benchmark RSA and XTR? If this is your own software please say so
and
> tell us what tricks you used to implement RSA and XTR (Karatsuba?
Montgomery
> multiplication? addition-chains for exponentiation?). If it doesn't use
> Karatsuba for example then Table 1 overstates the relative advantage of
XTR
> over RSA. If the software is not your, it seems really bad form to not
give
> attribution. Surely even someone who writes "generic software" deserves
credit?
For the RSA comparison we used all the standard tricks: CRA, montgomery
multiplication, sliding windows exponentiation, karatsuba and we have tried
everything to avoid that unfair comparison (not that I think that anyone on
this list believes that). And yes the software is our own (actually Arjen
Lenstra's;
he has written Freelip, remember).
Eric
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: XTR (was: any public-key algorithm)
Date: Fri, 2 Jun 2000 14:04:01 +0200
Roger Schlafly <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Eric Verheul wrote:
> > > I agree with you. XTR is not any less susceptible to those
> > > attacks. In the case of your code, the attacks will depend
> > > on mod p arithmetic times or power usages depending on the
> > > data, or on whether the conditional branch can be detected.
> > > But the XTR algorithm in the paper has the same problems.
> > Then please *show* me a DPA attack.
>
> A DPA attack will depend on implementation details that you
> have not specified. You have an argument that such an attack
> will be hard, but I don't see an argument that it is any
> harder than on Ian's pseudocode.
Look. We ended up with this XTR exponentiaton algorithm where the only
design criterion
was speed, and it turned out it had some intrinsic DPA resistance, i.e. more
resistance than
a *standard* exponentiation routine. We thought that was nice. Whether or
not it is more resistance
than Ian's pseudocode I don't know (but nor do you), but that is not what we
claim, right.
On the other hand, Ian's pseudocode will slow down the standard
exponentiation, and ours will not.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Contest rule proposal
Date: 2 Jun 2000 12:44:49 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> Similarly for IDKA (minus for-profit usage). Of course if anyone
> patents their sci.crypt submission they have problems.
If you mean IDEA, the for-profit licence fees are sufficient for it not
to be usable in DFSG-free softwate.
> BTW ever wonder if the CAST sboxes are magically cool, why they
> use rotations/etc in the round function? Me thinks they are
> just being wierd and obtuse. They could simplify the whole
> thing and boast 'we have a simple algorithm'.
The most painful bit I can see is the CAST-128 key schedule, which is a
truly horrible thing.
-- [mdw]
------------------------------
Subject: Re: Contest rule proposal
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 05:45:04 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Mark Wooding) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>> Similarly for IDKA (minus for-profit usage). Of course if
anyone
>> patents their sci.crypt submission they have problems.
>
>If you mean IDEA, the for-profit licence fees are sufficient
for it not
>to be usable in DFSG-free softwate.
>
>> BTW ever wonder if the CAST sboxes are magically cool, why
they
>> use rotations/etc in the round function? Me thinks they are
>> just being wierd and obtuse. They could simplify the whole
>> thing and boast 'we have a simple algorithm'.
>
>The most painful bit I can see is the CAST-128 key schedule,
which is a
>truly horrible thing.
That too.
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!
------------------------------
Subject: Re: Weak Keys in TC3
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 05:45:56 -0700
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
>(TC3 is a block cipher I am working on. It's on my website)
>
>I found the first class of weak keys...If the 6 key words are
>all equal to -F(x+1), 0<x<7, then encrypting all zero makes an
>all zero output. The prob of getting this key is 2^-192 and it
>requires only one chosen plaintext to detect.
>
>I think the attacks 'if a = c then' will work as well because
>all you need is 'if (a + F(1)) == (c + F(4))) then' etc... which
>means there are whole classes of bad keys.
>
>Conclusion: The key schedule in TC3 is a poor design. Shame on
>myself.
>
>Any ideas on how to fix it? Should I use a fullblown key
>schedule?
>
>Tom
>
On second thought I don't see how truly random round keys can
avoid the relationship. I think they are sufficiently non-
probable that makes the keyschedule ok.
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: Roger Williams <[EMAIL PROTECTED]>
Crossposted-To:
news.admin.net-abuse.usenet,alt.privacy.anon-server,alt.vacation.las-vegas,ne.general,alt.anonymous
Subject: Re: UDP Cotse
Date: 2 Jun 2000 12:06:34 GMT
Also spracht Chuck Kohlenberg:
> In <[EMAIL PROTECTED]>, Charles Demas posted:
>>In article <20000601191751$[EMAIL PROTECTED]>,
>>Damn! Spam from Bellglobal is way down this week.
>>
>>Looks like chances that they'll be UDPed are getting pretty small. :~(
> Get that Spamhause COSTE instead.
Cry us all a river, Chuckles. I think Steve Gielda's documentation of
your shameful affair shows what kind of bitter kook you are. Or would you
like to try screaming at his wife again and have *her* tell you?
--
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{} \|/
{} RogerW [EMAIL PROTECTED] {} 0< -- parrot.net!
{} http://www.parrot.net [EMAIL PROTECTED] {} ^^^^(*)^^^^
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{} ^^ / \ ^^
------------------------------
From: "norman" <[EMAIL PROTECTED]>
Subject: Re: Free Crypto-Lib for VB?
Date: Fri, 2 Jun 2000 15:12:11 +0200
try http://www.kewlstuff.co.za.... we use it ( it is good, not free)
"Charles" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm looking for a free cryptography library full of vector-tested
> algorithms, either in BAS, OCX or DLL format, which are usable in a
> Visual Basic environment. I realise that VB is the poorest choice for
> a language involving crypto, but I would appreciate some help in
> finding something.
>
> I have had limited success, once finding a vector-verified Blowfish
> DLL, and another in a group of BAS files with the hashes MD5 and
> SHA-1, and the cipher RC4, but MD5 didn't verifiy against the
> vectors...so scrap that one.
>
> Anyone know where I can find a free crypto-lib for VB? (particularly
> including an implementation of SHA-1).
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Contest rule proposal
Date: Fri, 02 Jun 2000 13:53:46 GMT
On 2 Jun 2000 10:38:41 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>Andru Luvisi <[EMAIL PROTECTED]> wrote:
>
>> I propose a rule that all algorithms for the sci.crypt crypto contest
>> must be in the public domain. Please note, I am talking about the
>> algorithms, and not the sample code.
>
>I have a simpler proposal: require the code in the submissions to be
>DFSG-free, i.e., free software within the meaning of the Debian Free
>Software Guidelines (http://www.debian.org/social_contract#guidelines).
I have an even simpler proposal: the patent holder offers fair use of
the patented techniques within the non-commercial context of the
context. I certainly would not agree to someone else's definition of
"free software."
>I believe that this will permit analysis and use of source code provided
>with the submissions[1], and require the algorithms to be usable without
>worrying about patents. I don't mind if the algorithms are patented as
>long as that's not an encumbrance, and that there's a worldwide royalty-
>free licence granted to use the invention.
I don't guess you would. A worldwide royalty-free license might as
well mean there was no patent at all. And that's exactly why I did
not participate in AES. If any contest is to see all available
techniques, it must allow patented techniques as well.
>And I'm certainly not wasting my time analysing algorithms which someone
>wants to make money from.
It's not about *you*: If *you* don't want to analyze an algorithm,
that's your decision.
On the contrary, *you* who want to make it impossible for *others* who
own patented ciphers to compete against those who hold no such rights.
This is an issue which is obviously not science.
Everybody wants a free lunch. If we just pass a law demanding free
lunches, everyone can eat. Right?
>[1] This is important. I want to be able to swipe bits of the example
> source code to strap it into programs which perform differential
> analyses, for example. Having to reimplement the cipher to do this
> simple stuff isn't my idea of a good time.
That sounds like ordinary fair use to me.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Contest rule proposal
Date: Fri, 02 Jun 2000 14:48:49 GMT
On Fri, 02 Jun 2000 13:53:46 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Terry Ritter) wrote:
>[...]
>I have an even simpler proposal: the patent holder offers fair use of
>the patented techniques within the non-commercial context of the
>context.
======^=
That would be: "contest."
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Contest rule proposal
Date: 2 Jun 2000 14:59:11 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
> I don't guess you would. A worldwide royalty-free license might as
> well mean there was no patent at all.
That's clearly not what Adams and Tavares thought when they granted such
licences for CAST-128 and CAST-256. And it's clearly not what RSA
Security Inc. thought when they submitted RC6 to the AES contest.
> And that's exactly why I did not participate in AES. If any contest
> is to see all available techniques, it must allow patented techniques
> as well.
I could go into a patents rant at this point. I'll try to resist, and
instead pick at the word `available': the `availability' of a patented
cipher is qualititively different from the `availability' of a free
cipher.
> This is an issue which is obviously not science.
Clearly. If all we wanted to do was to make scientific progress, we
should just get on and do that. But it's not that simple: people seem
to want to make money at the same time, and that's where the problem
comes from.
> Everybody wants a free lunch. If we just pass a law demanding free
> lunches, everyone can eat. Right?
I'm not so fussed about paying for lunches. Each individual lunch takes
time and effort to prepare. [There's a long off-topic rant about this
distinction, which I'll omit.]
On the subject of free lunches, though, isn't there something of the
same sort in presenting your cipher, which you plan to cash from, for
review and analysis from people in their spare time?
-- [mdw]
------------------------------
Subject: How RSA SecurID tokens work?
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 07:58:58 -0700
Given the serial number and the current time how does the RSA
SecurID tokens create their PIN outputs?
I was sent a "demo" batch from RSA, and I can't use their win32
api...
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: Thomas Kellar <[EMAIL PROTECTED]>
Subject: http://www.infraworks.com product
Date: Fri, 2 Jun 2000 11:10:13 -0400
I have been receiving advertisements from a company
called the Infraworks Corporation. They apparently have
made a new product they cann InTether that they claim
can control access to files of any sort.
from their web page:
---QUOTE---
Until now, digital files emailed or downloaded over the Internet have been
available to anyone to copy, print, distribute and view indefinitely. With
Infraworks breakthrough technology, InTether, digital file owners can
send, sell, and control content, with sender-established conditions, with
the confidence that the document security is impenetrable. InTether
enforces sender-established permissions to prevent reproduction and
redistribution of digital files by users. Unlike other weaker protection
approaches like encryption and watermarking, InTether's unique enabling
technologies and multiple layers of protection provide impenetrable
protection for any digital file.
---UNQUOTE---
They don't seem to understand that with a debugger running on your
desktop, you can make their software do whatever you want. They
also state on the "key features and benefits" page that Intether
"Meets and exceeds U.S. Department of Defense standards." I don't
know why but that does not give me any warm fuzzy feelings.
They give an example scenerio where you want to send a file to
someone and only allow them to read it once, the the document
will then self destruct. Even if I do not use a debugger to bypass
their controls, I can get out my trusty digital camera and take
pictures of the VDU screen.
http://www.infraworks.com/products/intether.php3
Thomas
--
w8twk Freelance System Programming http://www.fsp.com
------------------------------
From: Adrian Kennard <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,uk.telecom
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Fri, 02 Jun 2000 15:46:30 +0100
Dave Howe wrote:
>
> In our last episode (<alt.security.pgp>[Wed, 31 May 2000 08:41:29
> +0100]), George Edwards <[EMAIL PROTECTED]> said :
> >How on earth can anyone prove that you HAVEN'T forgotten your key,
> >unless you suvsequently use it? I see huge legal bills on this, all fees
> >for the solicitors.
> They don't have to - it is up to you to prove you have; *that* is what
> is so worrying.....
Proving you have forgotton a key *should* be easy though - surely.
"Hmmm, nope, I cant remember it" - proved.
--
_ Andrews & Arnold Ltd, 01344 400 000 http://aa.nu/
(_) _| _ . _ _ Professional Voice and Data Systems for Business.
( )(_|( |(_|| ) Gold Certified Alchemists, BT ISDN/ADSL Resellers
------------------------------
From: Marek Futrega <[EMAIL PROTECTED]>
Subject: Solovay-Strassen primality test
Date: Fri, 2 Jun 2000 17:14:25 +0200
The basis of the Solovay-Strassen algorithm is the fact that for any
given composite number "n", there are at most n/2 values of "a" less than
"n" for which "n" is an Euler pseudo-prime with base "a".
I'm looking for a proof of this fact. Any ideas where to find it?
thanks,
M.
ps. If possible, please CC your answer to [EMAIL PROTECTED]
___
[EMAIL PROTECTED]
http://rainbow.mimuw.edu.pl/~maf
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RSA/PK Question (You should do your homework first, you know this
conversation can go on for longer than breaking your overly small 768-bit keys)
Date: Fri, 2 Jun 2000 08:42:04 -0700
The entire basis of your argument was that it's good enough for now. I
simply asked why you did not find the other comparison correct. You have
continually stated that only 768 bit RSA keys are needed, and you have
continually been corrected that there is a for now that you continually
ignore, and have even stated cannot exist. This is the same level of error
that allowed Rivest to make grossly wrong claims about the strength of RSA,
stating that it would take a phenomenal amount of time to break 160-bit RSA
keys, when in fact now, less than 30 years later, I can break those same
keys on the machine in front of me in times that make them certainly broken.
In the reality that I live in, we continually develop better algorithms,
ones which take less time and less space than the ones before. We also
continually develop better computers to run these algorithms. You again
claim that 80-bits is secure for now, but within moore's law they will only
be secure for less than a decade, I personally quite often have secrets that
need to be kept far longer than that, so again I say to you that your
estimates are vastly off, you have been corrected many times and continue to
make them. When people point out (quite gently the first few times I might
add) that you were incorrect, you return with things like "You are a
pragmatic jerk, you know that right?" (BTW I do know that I can be well
beyond a jerk on occassion).
You continually underestimate what is possible, and continually make
statements that you have certainly not thought out clearly, your suggestion
to use 768-bit RSA keys was roughly equivalent to using 64-bit symmetric
keys, which we all (in this I even include you based on your recommendation
for 80-bit symmetric keys) agree is too small. In order to get 80-bits worth
of protection we will have to go to at least 1024-bit RSA/DH public keys,
and most likely by the end of the year they will have to be bigger still.
Joe
"tomstd" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <O04uc$3y$GA.187@cpmsnbbsa09>, "Joseph Ashwood"
> <[EMAIL PROTECTED]> wrote:
> >You and I both know that many of us (including myself) have
> >corrected you on this time and time again. If you are so
> >focused on only protecting against the right here right now,
> >why don't you use a 57 bit key? 56 bit's is the largest
> >that's been publically done, 64-bits has been going on for a
> >long time now, so 57 bits is good enough for now. Instead we
> >have as a community gone with AES at 128 bits minimum. You
> >seem to be very much the exception here, instead of the rule
> >you think you are.
> > Joe
>
> Although I should be doing my Bio I felt like reading the
> group. You are a pragmatic jerk, you know that right?
>
> I never said to use 57-bit symmetric keys. In fact I said to
> use 80-bits as the minimum for right now. I also said to use
> 768~1024 bit RSA keys because they can't be solved right now.
>
> I also don't agree with using 128+ bit symmetric keys because it
> provides a false sense of security. "Oh it's secure because I
> use a 256-bit symmetric key", big deal.
>
> Anyways, I am back to studying my bio, and please don't put
> words in my mouth.
>
> 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: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Contest rule proposal
Date: 02 Jun 2000 08:33:45 -0700
[EMAIL PROTECTED] (Mark Wooding) writes:
> Andru Luvisi <[EMAIL PROTECTED]> wrote:
>
> > I propose a rule that all algorithms for the sci.crypt crypto contest
> > must be in the public domain. Please note, I am talking about the
> > algorithms, and not the sample code.
>
> I have a simpler proposal: require the code in the submissions to be
> DFSG-free, i.e., free software within the meaning of the Debian Free
> Software Guidelines (http://www.debian.org/social_contract#guidelines).
I'm not sure if that is more or less restrictive than what I was
proposing, but I would be fine with that as well.
You hit the nail quite squarely on the head: Why should we give a
designer no cost analysis when he won't give us the algorithm for no
cost?
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Weak Keys in TC3
Date: Fri, 2 Jun 2000 08:36:22 -0700
tomstd <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> (TC3 is a block cipher I am working on. It's on my website)
>
> I found the first class of weak keys...If the 6 key words are
> all equal to -F(x+1), 0<x<7, then encrypting all zero makes an
> all zero output. The prob of getting this key is 2^-192 and it
> requires only one chosen plaintext to detect.
If the weakness is "if you use a particular key, then encrypting a
particular plaintext will yield a particular ciphertext", well, that's a
"weakness" that's in all block ciphers. Or, in other words, not
particularly a weakness at all.
Suppose the attacker picks the key K=0x12345678...12345678, and encrypts
0x333...333 with it. He will get some ciphertext. This gives his a "one
chosen plaintext" method of detecting when key K is being used. However,
that observation is really no stronger than brute force.
(Now, if there are more than 192 bits of key, and setting 192 of those bits
to specific values gives you the weakness, then, yes, this is a "weaknes",
although arguably a minor one)
--
poncho
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: Fri, 02 Jun 2000 15:53:38 GMT
EE Support wrote:
> On Sat, 27 May 2000 18:45:54 -0400, jungle <[EMAIL PROTECTED]>
> wrote:
> >very cool post, thanks ...
> >
> >but the EE spam will be ON again very soon ...
> >
>
> Hi,
>
> EE Tech Support here.
>
> You've been using your jungle.net address to post negative posts
> against our software for some time haven't you?
I don't know who you are. I have never heard of you or your company. However,
you are conducting yourself in a very unprofessional manner. Neither I nor my
employer will ever buy a product from a company whose employees conduct
themselves in such an unprofessional manner.
In particular, spamming this newsgroup with excessive and/or uninformative
postings is NOT professional behavior, and should be avoided if you want
anybody to consider your product in a serious manner.
You may also wish to have your "web site team" (you?) revise your web site to
contain:
1) Contact information, including mailing address and EMAIL addresses for
sales, support, and marketing departments (even if they all go to you!), and
2) Get rid of all those animated GIFs, which are EXTREMELY unprofessional in
nature. It has the same effect as use of the <blink> tag.
In short, if you wish to be considered seriously by security professionals,
you must act like a professional.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
** 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
******************************
