Cryptography-Digest Digest #451, Volume #12 Tue, 15 Aug 00 14:13:00 EDT
Contents:
Re: Crypto Related Professional Attitude (Terry Ritter)
Re: Unauthorized Cancel Messages ("Paul Pires")
Re: PGP Algorithm (David Crick)
Re: Impossible Differentials of TC5 (David Eppstein)
Re: Unauthorized Cancel Messages (fvw)
215 Hz five-qubit quantum processor (Stanley Chow)
Re: New quantum computer - any details? (SCOTT19U.ZIP_GUY)
Re: Not really random numbers (Anthony Stephen Szopa)
Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ? ("Tor Rustad")
Re: Unauthorized Cancel Messages ("Paul Pires")
Re: 215 Hz five-qubit quantum processor (Ian Kemmish)
Re: Impossible Differentials of TC5 (tomstd)
Re: Unauthorized Cancel Messages (fvw)
Re: PGP Algorithm (tomstd)
Attacks on Feistel Networks (tomstd)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Crypto Related Professional Attitude
Date: Tue, 15 Aug 2000 17:16:18 GMT
On Tue, 15 Aug 2000 10:08:13 -0500, in
<[EMAIL PROTECTED]>, in sci.crypt James Felling
<[EMAIL PROTECTED]> wrote:
>[...]
>THe big names have alot on their plate, and since there are those on
>these NG with a desire to "take down" a big name crypto guy, they are
>much more prone to spam and nasty gram and other such counter posting
>tendencies.
I suppose there is some of that, but the whole point of a discussion
is to *discuss*, and discussion here is commonly about *differences*.
If the big name has been saying things which seem wrong, those issues
need to be confronted, just like with anybody else. That can be a
very abrupt change for someone used to adulation and passive general
acceptance.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Unauthorized Cancel Messages
Date: Tue, 15 Aug 2000 10:12:42 -0700
It happens to my posts. They don't linger as long as most. I my case, it's
probably a plus. I think it is just different behavior for different
servers.
Paul
fvw <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> <[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
> >It appears to me that someone is sending bogus cancel messages to
> >sci.crypt and the alt.security.* groups. My newsreader shows several
> >"This message is no longer available" messages for several legitimate
> >messages. This are clearly not anti-spam cancels as they are new
> >responses to postings. Has anyone else seen this?
>
> Nope, haven't seen this behaviour. But afaik, rogue cancels (or in
> fact any cancels) would delete the entire article, headers and all,
> so you'd never know it was there. This sounds more like a newsserver
> that's expiring articles to soon, or isn't saving the bodies because
> of lack of diskspace. Hmm, come to think of it, all these cases should
> really delete both entries in the group headers list as the bodies,
> so really those messages you're getting could be considered bugs.
> However, I am aware of several ISPs that have newsservers that do
> keep headers for expired messages for a bit longer.
>
> DISCLAIMER: I've very little experience with nntp/newsservers,
> ignore this message.
> --
>
> Frank v Waveren
> [EMAIL PROTECTED]
> ICQ# 10074100
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: PGP Algorithm
Date: Tue, 15 Aug 2000 18:18:18 +0100
Mark Wooding wrote:
>
> Runu Knips <[EMAIL PROTECTED]> wrote:
>
> > Cast5(?)
>
> For some reason, this is another name for CAST128.
Cast5 has both 80 and 128-bit versions.
--
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] RSA 22D5C7A9 DH BE63D7C7 87C46DE1 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: David Eppstein <[EMAIL PROTECTED]>
Subject: Re: Impossible Differentials of TC5
Date: Tue, 15 Aug 2000 10:22:07 -0700
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
> Ok still at some point you must attack the 64/32/16 bit
> feistels. I want to know how you do that please.
As I understand it, you don't. You just attack the 128-bit ones,
treating everything else as a black-box F-function.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Re: Unauthorized Cancel Messages
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 Aug 2000 17:28:42 GMT
<mXem5.48638$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>It happens to my posts. They don't linger as long as most. I my case, it's
>probably a plus. I think it is just different behavior for different
>servers.
Hmm, is your newsreader setting an Expires: header?
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: Stanley Chow <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: 215 Hz five-qubit quantum processor
Date: Tue, 15 Aug 2000 17:38:16 GMT
Since no one has mentioned it, the new quantum computer is being
presented at HotChips 12. According to the program at
http://www.hotchips.org/hotc12_tuesday.html
first thing on Tuesday morning.
I hope someone will post a summary.
The article on IBM
http://www.research.ibm.com/resources/news/20000815_quantum.html
is flufy, but points to an exceptional good article at
http://www.techreview.com/articles/may00/waldrop.htm
and to HotChips.
For the people on sci.crypt: note that it is only 5 bits, and please
read the articles before jumping to conclusions.
For the people on comp.arch: talk about executing both sides of a
branch!
--
Stanley Chow VP Engineering [EMAIL PROTECTED]
Cloakware Corp (613) 271-9446 x 223
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: New quantum computer - any details?
Date: 15 Aug 2000 17:26:10 GMT
[EMAIL PROTECTED] (Ed Suominen) wrote in
<HLem5.48347$[EMAIL PROTECTED]>:
>"Stanley Chow" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> There is (a little) more detail at
>> http://live.altavista.com/e?efi=980&ei=2087325&ern=y
>
>Quote from the article:
>"This phenomenon permits a quantum computer to have enormous power,
>Chuang said. For certain types of calculations, like complex algorithms
>for cryptography or searches -- a quantum computer using several hundred
>more atoms in tandem would be able to perform billions of calculations
>at the same
>time."
>
>Time for bigger keys or a switch to GF(p) ECC, methinks...
>
Or you could switch to something with a really BIG key
that treats a whole file like one encryption block such
as in scott19u.zip
>--
>Ed Suominen
>Registered Patent Agent
>Web Site: http://eepatents.com
>PGP Public Key: http://eepatents.com/key
>
>
>
>
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Not really random numbers
Date: Tue, 15 Aug 2000 10:34:02 -0700
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > James Felling wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > >
> > > > Jamie wrote:
> > > > >
> > > > > In the UK pre-Pay phone cards are big business... you buy a card, reveal a
> > > > > number, key the number to a phone system and you have so much talk time. I
> > > > > am working on an application in a simmilar field...and ofcourse the issue of
> > > > > generating these numbers has come up once again. I need ideas for a number
> > > > > generator that satisfy the following contidions:
> > > > >
> > > > > 1 The magnitude of the generated numbers can be specified, 2^30, 2^35,
> > > > > 2^40... 2^90
> > > > >
> > > > > 2 The period must be greater then 2^^20
> > > > > (So numbers generated dont repeat)
> > > > >
> > > > > 3a Given a short fragment of the sequence it must be difficult to deduce the
> > > > > next number in sequence
> > > > > 3b Given one number it must be unlikely that another number is both close in
> > > > > value and close in position in the sequence
> > > > > (vague but I guess I mean that a "hacker" wont succed randomly guessing the
> > > > > next number)
> > > > >
> > > > > 4 The sequence must be re-startable.
> > > > >
> > > > > 5 No need for an even distribution or anything like that.
> > > > >
> > > > > My starting point was an algorithm like
> > > > >
> > > > > Nn+1=(P1*Nn+P2) mod P3
> > > > >
> > > > > P1,2,3 are primes P3 determining the magnitude of the numbers generated
> > > > >
> > > > > Nn+1 the next number in the sequence
> > > > >
> > > > > But this seems to be full of holes.
> > > > >
> > > > > any ideas on an algo ?
> > > >
> > > > Go to http://www.ciphile.com and download OAR-L3: Original
> > > > Absolutely Random - Level3 random number generator shareware
> > > > software.
> > > >
> > > > Go to the Downloads Currently Available web page and download the
> > > > software directly. You will be able to generate more random numbers
> > > > than you could conceivably ever need.
> > > >
> > > > If used according to recommendations there is practicably no chance
> > > > anyone will be able to duplicate your random numbers.
> > > >
> > > > If you think you could use this software commercially, email me.
> > > >
> > > > A.S.
> > >
> > > Unless you have a desire for keysetup to take a truly ridiculous amount of time (
> > > realisticly obtaining a the level of internal randomness you desire is possible,
> > > but this will take aproximately 1/2 to 1 full hour of your time per keysetup)
> > > OAP/OAR are not worth your while, and are in all probability slower than an
> > > optimized BBS generator.
> >
> > This reply post has a glimmer of intelligence within it.
> >
> > It may take an hour or even more to generate a suitable initial
> > encryption data file key using OAP-L3 that will be used to generate
> > the initial (and secure) encryption Data FILE.
> >
> > (You need to be familiar with the software and how it generates its
> > random numbers to understand this process. Also consider that with
> > each subsequent generation of an encryption data file from a previous
> > encryption data file, the complete key continues to become longer
> > and longer (and increasingly more secure) since it builds on the
> > previous key(s).)
> >
> > But once you do so, a subsequent encryption Data FILE can be
> > generated from this now secure initial encryption Data FILE, and any
> > other subsequent encryption Data FILES can be generated from the
> > previously generated encryption Data FILE, thus each subsequent
> > encryption Data FILE after this initial one will be much less time
> > consuming to generate.
>
> I must state this. Files of this nature can be manufactured by other PRNG's. They
> will be manufactured as quickly if not more so, and as securely, if not more so.
>May I
> suggest an apropriately tweaked RC4, or BBS for your use. The issue is it will take
>~1
> hour of operator time to start generating good data with your mechanism, and it will
> also take more than a bit of time after that to actually generate the numbers. OTOH,
> it will take 1 minute to setup a good RC4 generator, and it will have generated a
> reasonable quantity of data( equivalent to your files) in under a half hour.( I think
> the fact that it takes less of MY time, and is done before OAP/OAR gets started is a
> HUGE advantage.) BBS is slower, but substantially more secure. It will probably
>take
> 5 minutes of my time to setup, and generate an amount of data sulficient to be useful
> in several hours. This is speed wise compeditive with your system, and is going to be
> more secure than your system in general.
>
> >
> >
> > The current implementation requires that you generate all your OTP
> > files before you encrypt. You could generate many many gigabytes of
> > random data files and store them while your computer is not being
> > used for anything else, such as while you are sleeping.
>
> Ummm... given you are using a stream cypher compare it with other stream cyphers --
>the
> big issue is speed of generation.
>
> >
> >
> > As far as speed of encryption goes, the actual encryption may
> > actually be the fastest of any encryption software. It only
> > involves XORing the original data file with the random number files.
> > Since the random number files have already been generated this
> > process is quite fast.
>
> RC4, BBS, and all others when saved to files encrypt just as fast as your method --
>The
> issue for the user is forufold
>
> 1) how much of my( the user) time do I wish to invest. (ideally as little as
>possible)
>
> 2)how much computer time do I wish to invest (ideally as little as possible)
>
> 3) how much space on my machine/ the remote machine do I want to use for this, (
> ideally as little as posssible)
>
> 4) How long is key data going to be lurking in an available form in my/remote PC. (
> ideally for as short a period as possible)
>
> versus RC4 you lose on all 4 points.
> versus BBS you lose on points 1,3,4 and cannot deliver security with an equivalent
> degree of confidence.
>
> You have a second rate stream cypher -- it is slower than most BLOCK algroithims. I
> admit that using large "random files" will give a speed enhancement, but they add
> secondary points of attack to your algorithim, and any other stream cypher, and most
> block cyphers can do the same trick faster.
I think your confidence level is not warranted.
"is going to be more secure than your system in general." This is
clearly over reaching.
"1) how much of my( the user) time do I wish to invest. " This is
certainly a (modest) concern. It is answered by asking yourself how
much more secure is OAP-L3 than other methods. As you should know,
OAP-L3 uses no mathematical equations in generating random numbers.
There is no modulo operation, for instance. In other words, there
are no inherent constraints in the random number generation process.
With no constraints there is no way to trivialize cracking the
random number generator. This may make the additional time worth
it. Besides, the time need be invested only once since you will be
able to generate more random numbers than you could ever possibly
need with very very little additional effort.
"2)how much computer time do I wish to invest?" This point also
addresses the limited cost of using OAP-L3. You cannot simply look
at cost. As above you must look at what you are getting for your
cost. See below.
"3) how much space on my machine/ the remote machine do I want to use
for this,..." This is a valid cost concern. See below.
"4) How long is key data going to be lurking in an available form in
my/remote PC." This is valid security concern.
Here is my response to the remaining concerns:
You may be aware that OAP-L3 Version 4.1 / 4.2 is the original
implementation of the theory / concept. This implementation has
the cost concerns that you have a legitimate reason to point out.
And you may not be willing to incur these costs.
My proposed implementation for Version 5.0 is available at
http://www.ciphile.com from the What's Ahead web page.
Version 5.0 is explained in detail in the files available for
download by clicking the blue anchors located at the bottom of
this page: Version 5.0 Tables file and the associated Version
5.0 Text file.
Version 5.0 will not require you to generate random number files
beforehand. Permanent hard drive space will not be required because
the key / encryption data will be kept on floppy. This pretty much
dispels #2, #3, & #4.
I addressed #1 initially, above.
Depending on which variation of version 5.0 one uses, the
encryption time will vary.
Here is a brief description. Full details by clicking the blue
anchors at the bottom of the What's Ahead web page.
("E" notation means that a number expressed as 5E6 = 5 x 10^6 or
5,000,000.)
With only 2920 data bytes you will be able to generate 9.2E15 random
numbers from 0 - 255 with a security level equivalent to 2000 bits;
or with only 4600 data bytes you will be able to generate 2.3E17
random numbers from 0 - 255 with a security level equivalent to
10,000 bits;
or with only 1,271,000 data bytes (fits on one floppy) you will be
able to generate 1.3E36 random numbers from 0 - 255 with a security
level equivalent to 100,000 bits.
The Version 5.0 Tables file and the associated Version 5.0 Text file
describe how this is done.
You don't need to keep the key / encryption data on your computer.
Keep it on a floppy disk. Insert it when needed then remove.
Thanks for your consideration.
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ?
Date: Tue, 15 Aug 2000 19:40:21 +0200
"Mark Currie" <[EMAIL PROTECTED]> wrote in message
> In article <XU8l5.1087$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> < snip >
> >
> >The WAP GW is a true man-in-the-middle, but this is not the most difficult
> >sucurity problem for me. Today many transactions go trough GW and routers
> >without being a major security risk, we already have secure means/protocols
of
> >doing this.
>
> Yes, if you add extra crypto on top of WTLS and SSL you can defeat the "gap"
> but then you don't need WTLS and SSL. This will probably happen with banking
> apps but for normal e-commerce as it is now done on the web using SSL, the
> industry needs a standard and that is what WTLS is supposed to provide but as
> yet it doesn't provide e2e.
I have not yet studied WTLS in detail, but from what I have seen, it has more or
less equivalent functionality as SSL. Hence, authentication and confidality can
be implemented with it. That may be important to telecom, but to me digital
signature of the transaction is more important.
What you call "normal e-commerce w/SSL", is what the push towards EMV and SET,
is supposed to stop...
> >The problem starts with the chip (SIM/WIM), as long as the banks
> >have no control over this security, we simply can't design a system with
> >end-to-end security. It doesn't matter how secure the WAP GW is, if we can't
> >trust the chip card used the mobile phone, there is no way to trust the
> >transaction.
>
> This may not always be true, it depends on what type of transaction you want
to
> do. If you are doing transactions that you can already do with SSL, then
> ignoring the problems with this method, I see no extra imposed problem using
> the Telco's SIM to store your ID/credit card number.
IMHO this does not make sense. For _starters_, I do not trust the security of
the SIM chip: not before, during or after it was produced.
> However, if you want to
> use the SIM as a cash card or wallet then I agree, cash cards will always have
> to meet with bank's approval.
and the national bank approval. If somebody is able to generate a lot of e-cash,
an economy in a country can collapse, the national banks do very much want to
control this (even if they don't now it yet).
> >There is a chain of trust, and it begins even before the chip is produced.
> >However, it doesn't help much that the A3, A5/1,A5/2 and A8 has been reversed
> >engineered, and some major design flaws where discovered during the proccess.
> >Even if these algorithms had been cryptographic strong, there are many other
> >important security issues like key management, card production, card issuance
> >etc.for which there are lessons yet to be learned for the mobile community.
>
> Perhaps if the Telco's were to get ITSEC-E4-high approval for their SIM's,
this
What does ITSEC-E4... prove? For me, the most interesting parts are not in such
reports, since they are incomplete.
Certifications are important, but you can't simply certify part of the product
and state that the product is secure. You also have different levels of
expertise at the certification bodies, some of them are not as good as others.
> would go some way to acceptance in the banking community. However, I realise
> that this would not be enough since the bank's want to see the whole
> manufacturing and delivery process (as you say - the chain of trust). The
> German banks have their own approval system for cash card's called ZKA.
Perhaps
> there needs to be an industry-wide standard like this.
There is already such an ISO standard, called common criteria. I don't know
GeltKarte much, but
am not suprised if the ZKA is detailed and at the upper end on security. I guess
the german SigG and DIN is too hard for the rest of EU...
> However, I think that
> one of the main problems here is that of billing. The Telco want their cut and
> the bank want theirs.
Sadly I agree. So for the time being, we will get a lot of poor solutions on
this.
> >We don't need to go into difficult areas at all, how can we view the mobile
as
> a
> >secure PIN entering device, when it is not designed as such? ATM and POS PIN
> >entring devices has encrypted keyboard controllers, my personal mobile bip a
> >different tone for each PIN digit I enter!
>
> This is a very valid point. I once posted something in alt.privacy about the
> problem of normal PC keyboard sounds, but this is much worse. With a bit of
> practise, you could even learn to recognise the tones yourself and not need a
> recorder of sorts. Of course the tones can probably be switched off, but the
> default is on and how many users switch it off ?
I am shure I can turn it off, but my point was only to illustrate the big
difference in design here. There are many other points as well. This is no
suprise, since such design issues has not been important to mobile community.
> >We have already seen some results of the two world problem, I know one mobile
> >phone which have internally two chip slots, one for the SIM and the other for
> a
> >bank ICC. In many pilots, the mobile has a built in smartcard reader, where
> you
> >can insert your bank card. Given the small size of a modern wireless phone,
> and
> >the size of a bankcard, this seem to lead into some practical difficulties. I
> >don't know yet any pilots where telecom and banks uses the same chip, I guess
> >there is a reason for this.
>
> There is also something that I would like to see changed - the mechanical
> format of a SIM or smart card. I can can understand some of the original
> motivation for the format of a hand-held smart card, i.e. wallet size etc. but
> I can't understand the motivation for the SIM card following the smart card
I see one good reason, the card manufacturing can be performed with the same
equipment.
> route. If the SIM were to be a just a bit thicker, we could put much more
> processing power/memory onto it. Then we could implement strong and fast
> cryptography on the SIM and develop substantial apps on the SIM.
The ICC world is still very much 8-bit, but I don't expect the quantum leap to
32-bit to be too far away.
--
Tor
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Unauthorized Cancel Messages
Date: Tue, 15 Aug 2000 10:42:21 -0700
fvw <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> <mXem5.48638$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
> >It happens to my posts. They don't linger as long as most. I my case,
it's
> >probably a plus. I think it is just different behavior for different
> >servers.
>
> Hmm, is your newsreader setting an Expires: header?
I'd love to answer that question. First one for me, how would I know?
I'm pulling newsgroups up in outlook. I looked at all the options and
settings and nothing rings a bell.
Paul
> --
>
> Frank v Waveren
> [EMAIL PROTECTED]
> ICQ# 10074100
------------------------------
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
From: [EMAIL PROTECTED] (Ian Kemmish)
Date: Tue, 15 Aug 2000 17:48:14 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>For the people on comp.arch: talk about executing both sides of a
>branch!
No, you only executed one side of the branch, but you're not allowed to know
which side until after the cat dies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ian Kemmish 18 Durham Close, Biggleswade, Beds SG18 8HZ, UK
[EMAIL PROTECTED] Tel: +44 1767 601 361
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Behind every successful organisation stands one person who knows the secret
of how to keep the managers away from anything truly important.
------------------------------
Subject: Re: Impossible Differentials of TC5
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 15 Aug 2000 10:35:03 -0700
David Eppstein <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
tomstd
><[EMAIL PROTECTED]> wrote:
>
>> Ok still at some point you must attack the 64/32/16 bit
>> feistels. I want to know how you do that please.
>
>As I understand it, you don't. You just attack the 128-bit
ones,
>treating everything else as a black-box F-function.
Technically the F function has a 128 byte (1024 bit) round key
associated with it. It's not as simple as the round key being
xor'd in though... I still don't see how the attack works, if
it does even at all.
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Re: Unauthorized Cancel Messages
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 Aug 2000 17:44:24 GMT
<ckfm5.49440$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>
>fvw <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>> <mXem5.48638$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>> >It happens to my posts. They don't linger as long as most. I my case,
>it's
>> >probably a plus. I think it is just different behavior for different
>> >servers.
>>
>> Hmm, is your newsreader setting an Expires: header?
>
>I'd love to answer that question. First one for me, how would I know?
>I'm pulling newsgroups up in outlook. I looked at all the options and
>settings and nothing rings a bell.
n/m, it's a stupid question, I can check for myself... If you posted
the message this is a followup to with the same newsreader on the same
machine you always do, it isn't setting any expires headers. Most
newsreaders have the option of 'view headers' when you're looking at
a message. I'm don't know how to do that in outlook though :-(.
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
Subject: Re: PGP Algorithm
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 15 Aug 2000 10:37:10 -0700
David Crick <[EMAIL PROTECTED]> wrote:
>Mark Wooding wrote:
>>
>> Runu Knips <[EMAIL PROTECTED]> wrote:
>>
>> > Cast5(?)
>>
>> For some reason, this is another name for CAST128.
>
>Cast5 has both 80 and 128-bit versions.
As long as you don't use the original CAST key schedule you're
ok. I developped a class of weak keys for CAST as presented in
Applied Crypto.
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Attacks on Feistel Networks
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 15 Aug 2000 10:48:15 -0700
In this (draft) paper I show how in some instances ciphers like
CAST can fall to attacks (linear cryptanalysis in this case)
when very specific types of keys are used. In the original CAST
for example a bad key can be chosen with a probability of about
2^-16.
The paper is at
http://www.geocities.com/tomstdenis/files/fna.ps
Please comment on it.
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
** 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
******************************
