Cryptography-Digest Digest #86, Volume #11 Thu, 10 Feb 00 03:13:01 EST
Contents:
*** Don't solve this *** (Muthukumar Senthil)
Re: I'm returning the Dr Dobbs CDROM (wtshaw)
Re: new standart for encryption software... (Eric Lee Green)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: A query method for communications ... (wtshaw)
Re: micropayments and denial of service? (Glenn Larsson)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: NIST, AES at RSA conference (David Wagner)
parece que me colge ("Matias C. Szmulewiez")
Re: micropayments and denial of service? ("Lassi Hippel�inen")
----------------------------------------------------------------------------
From: Muthukumar Senthil <[EMAIL PROTECTED]>
Subject: *** Don't solve this ***
Date: Wed, 09 Feb 2000 23:18:22 -0500
Sorry Guys:
I was just kidding about the monetary reward. It was just meant as joke
and anyway I don't want it to be solved as I am learning a lot myself trying
to figure it out. Thanks.
serialno23 wrote:
> Does anyone know how to break this code (or have any ideas):
>
> It was enciphered using a polyalphabetic substitution cipher (of key
> length 4) by one of the foremost security experts in the country. There
>
> will be monetary compensation involved. Pls. RSVP if you know how to do
>
> it. We have tried the basic things like frequency analysis, Kasiski
> method. Thanx.
>
> The message starts now:
>
> bpivm mdznk azfkw lexpl urqjf wsejm deopd gqeg. qnwju clsjn lcwea
> zfwpy vkdnw emzfk wlaew xohpy kpxzj xlhcm sjyer r,mxz cflco rgijr
> jlaji xqbjj m,urf mixjc puqqj o,pdg tjmwq epufw lcaky ajbfi jrtyo
> apcoe mvmmu gopuy olvjm kdfxj svfkw l.pdz nkazf jiewc scqcg pkmxz
> cflco rgior fvxrt jvbjj m,llf krvxp grval ldmij yrsvf flcjj duhme
> pemnj rmgio glyjr p,qcu zcvld voprx rliop ujabf rnmsu ox.cg mmjum
> ilmpx vdpgj rikuf peuwf dgoes cqcuc gmqzv krewc rrxbs jabfr bpddm
> pxvdp gvwcs dvbpx vfsru bwgqg ,rnpe bqbpc gmjyw fgwyb sztlk yqlc,
> qcuzr ejsop gcgmq rvbtj vrjhc mdznk azfkw lqxur tksvw cs.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Wed, 09 Feb 2000 22:40:07 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> > I suppose that text is TOO compact a format to use these days.
>
> No, but to capture formatting one needs more than just character
> codes. In the case under discussion, apparently the hardcopy was
> simply scanned directly into bitmap images, which captures every
> aspect of the printed format (with scanning resolution) in a
> simple way, at the cost of size. Raster images tend to be large
> compared to their useful information content.
Even html is better than muddy images.
--
Life is full of upturns and downturns, with varying periods of
stabilty mixed in. It is a fool's errand to assume that what is
happening any one day predicts the same as a constant future.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: new standart for encryption software...
Date: Wed, 09 Feb 2000 22:51:56 -0700
finecrypt wrote:
> Sounds like you never worked with Windows (and if so, why you value Windows
> specific program?) .
I don't quite understand. Yarrow itself is a Windows-specific program,
but the basic principles involved remain the same (/dev/random on Linux
and FreeBSD shares a lot of characteristics of Yarrow, except that
they're not quite as strong because they use MD5 rather than SHA1...
similarly, I wrote Ocotillo after reading Yarrow paper and /dev/random
implementation and a few other papers like David Wagner's Netscape hack
paper).
> Among pseudo-random values that has been retrieved
> during key generation (and I specified these values in my post ) there is
> such values as milliseconds since Windows started, types of events in input
> queue, 1 ms time for last message and so on. These values permanently
> changing during key generation. .
Note that I did not say that they did not change. What I said, rather,
was that they did not have as many bits of entropy as you imply. For
example, there is a counter in Linux that ticks off the number of
miliseconds. /dev/random looks at that counter just as you do -- but
does it non-deterministically, when disk I/O interrupts arrive, and if
the interval since the last disk I/O interrupt is greater than the
last-stored interval, it views this as a '1', otherwise it views it as a
'0' (either way, it stores the interval). Then it shifts this into its
shift register as a bit of entropy. Once 128 bits of entropy have been
gathered, they are stirred into the md5 pool. Meanwhile, there is
another pool going tick...tick...tick away, incrementing a counter
(added to the md5 checksum) for every request for byte, and it gets the
128 bits of entropy too. So basically you have two pools here -- one
that is completely random but has very few available bits, and one that
is pseudo-random and is succeptible to flood attack.
Anyhow, the point is that the lower six bits of the millisecond counter
may have changed, but that doesn't mean you have that many bits of
randomness information contained there. Estimating randomness is an art,
and it's always better to under-estimate how much randomness is
contained in your sample than to over-estimate it. *READ THE YARROW
PAPER* at http://www.counterpane.com/yarrow.html . I keep repeating that
to you, but you don't seem to "get it".
> Slow for what? Entire cycle of key generation on PIII takes less than 0,1
> sec.
Err, what are you using to stir your entropy pool? A plain numeric
checksum? a variant of CRC checksum? A cryptographic-quality hash like
MD5 or SHA1?
--
Eric Lee Green [EMAIL PROTECTED]
http://members.tripod.com/e_l_green/
See: http://dvdmirror.tripod.com too!
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 05:52:22 GMT
On Wed, 09 Feb 2000 23:40:02 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> ... if someone can convince me that there is an actual
>> *contradiction* in my belief that multiciphering (with non-groupy
>> ciphers) must increase strength at least by the amount of
>> processing effort, that will, of course, change my belief.
>
>Well, besides having refined your original claim (which people
>objected to), you have also set yourself up to be able to simply
>claim that any counterexample is "groupy". In other words,
>whatever remains of the original "provably stronger" claim
>has no real force at this point.
It would be very nice if the reality of "provably stronger" was as
simple as you seem to think it should be. Unfortunately, it may be
necessary to include a whole string of assumptions before we get to an
acceptable proof. It seems quite reasonable to avoid dealing with a
structure which we know can cause problems if we can either measure
that it is not present, or if that structure can be made to not occur
with any reasonable probability. And we already know that the problem
is not restricted to the mathematical definition of groups, so there
is no technical name for it. In the end, adding a non-groupy
assumption would seem to be reasonable progress.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.politics.org.cia,alt.security,alt.2600
Subject: Re: A query method for communications ...
Date: Wed, 09 Feb 2000 23:13:33 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Conversely, you can update your web pages in some specific ways
> to broadcast certain intelligence without outsiders noticing that,
> I suppose.
Of course you can. But, it might be of interest to see who went after
that material.
--
If Al Gore wants to be inventor of the internet, complain that he
did a lousy job. If he admits to not doing much, complain that he
is a slacker. Now, do we want him in charge of security?
------------------------------
From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: micropayments and denial of service?
Date: Thu, 10 Feb 2000 06:51:42 +0100
[EMAIL PROTECTED] wrote:
>So, what effect would micropayments have on denial of service attacks?
Well, very little :o) but if you refrase that into:
"So, what effect would _denial of service attacks_ have on
_micropayments_?"
It depends, if the operating system it runs on is succeptible to a DoS
they it goes down/locks up <Whatever>: Install the latest patches from
your vendor and you should be "safe".
>I understand that denial of service attacks are usually done
>indirectly through compromised sites.
Wrong. Source of orgin forgery is standard practice.
Regards,
Glenn
P.S: This is NOT comp.security.misc
_________________________________________________
Spammers will be reported to their government and
Internet Service Provider along with possible legal
reprocussions of violating the Swedish "Personal
Information Act" of 1998. (PUL 1998:204)
This is punishable by a fine or 6 month to 2 years
imprisonment (Paragraph 49)
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 06:51:23 GMT
On Wed, 09 Feb 2000 22:29:56 GMT, in <87spos$3nk$[EMAIL PROTECTED]>, in
sci.crypt Bryan Olson <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> Paul Crowley wrote:
>>
>> >And here lies the crux of the argument. We haven't proven the
>> >strength of our ciphers, and you haven't proven the strength of your
>> >multiple encryption schemes. You're relying on just the reasoning
>you
>> >accuse us of.
>>
>> I dispute that. You have taken my words out of context and
>> misrepresented my position; while the words are similar, their meaning
>> is not.
>
>You miss the point. The greatest misrepresentation of
>positions has been your incessant ridicule of the
>"unscientific" reasoning of others. Over and over you
>lectured on how there is no mathematical proof of security
>to an audience that did not claim there is.
When one chooses to argue semantics, it is usually because the
fundamental position is obviously wrong, as it is here.
Of course, as long as you don't explicitly *say* that you support the
result of AES, you can say "Hey, I didn't say anybody should *use*
it!" It's sad, really.
It is clear to me that you think all we need to do is have some
academics check out candidate ciphers (even though we really don't
know how much effort anyone in particular has put into doing that),
then society should use the result.
Of course there is no science or logic which allows us to extrapolate
cryptanalytic negative results into strength, or probable strength, or
even trustable strength.
So instead of trying to innovate ways to minimize or eliminate some
attacks, or minimize the consequences of successful attack, you prefer
things the way they have been. You would have all of society depend
upon a few ciphers as though that were no risk at all, or there is no
way to reduce that risk.
>From the start we've been addressing the problem of
>achieving security in a setting where we can not prove we
>succeed. Whether one phrases the outcome as trusting a
>system we cannot prove to be secure, or as relying on a
>system we cannot trust, is irrelevant.
A cipher can have weaknesses about which we do not know, but which we
can address anyway. If we do address those weaknesses, then we have
fewer possible weaknesses than we had before. And if we do not, we
remain vulnerable to single-point faults which we cannot disprove and
also cannot test.
>> "We all know" that if the most favorable attack cannot be applied,
>> only less favorable attacks remain. This form of "we all know" is
>> simple logic and is based on facts and logical consequences. It means
>> that I expect the reader to bring some minimal context to the
>> statement.
>
>Your logic is deceptive. The "we all know" may be a logical
>truth, but it applies to the entire "if" and does not imply
>"only less favorable attacks remain". The consequent we
>really want still depends on "the most favorable attack
>cannot be applied" and that falls into the "everyone
>believes" category.
Apparently your semantic problem here is the possibility of equally
powerful attacks, and only that. But it does seem rather unlikely
that in reality two different attacks will each have exactly the same
power, in which case your distinction is meaningless.
>We only know what attacks _we_ favor, while it is the
>attacks that may hurt us are those that our adversaries
>choose. Are we justified in assessing what an adversary can
>do and might achieve based on our understanding? If not,
>then your logic above still yields nothing.
Nonsense. By adding things beyond the cipher (such as using multiple
cipher levels, and partitioning plaintext for protection under
different ciphers, etc.) we do not just reduce attacks, we complicate
or eliminate whole classes of attacks, and reduce whole classes of
risks.
>If so, then you
>owe a lot of retractions.
You owe *everyone* here a deep, heartfelt apology (which I expect to
never see) for your continued attempts to hide your weak position by
not stating it so that you do not have to defend it.
It is clear that you are not advocating not using cryptography. And
if you don't like adding things beyond the cipher, it seems reasonable
to assume that you think the cipher alone is enough. So your position
is that -- even though you cannot prove that particular cipher is
secure -- you are willing for society to take the risk that you are
wrong. Gee, how academic of you.
>[...]
>> We can agree that there are no -- and probably *can* be no -- provable
>> ciphers. But that does not mean that we must accept what we have. It
>> does not mean that there is no point in attempting to protect against
>> possible problems, or reduce their effects, even though the resulting
>> system is no more provably strong than the original.
>
>And that is why I am so happy with the AES effort.
Yeah, but that's you.
>> Such reasoning can be seen as a form of mathematical fallacy which is
>> often presented in early algebra, the "equality" of two infinities:
>> True, a cipher has infinite possibilities for failure, and true, a
>> multi-cipher also has infinite possibilities for failure, but it is
>> false that those two infinities are equal.
>
>Perhaps you missed the point in your algebra class too. The
>cardinality of the rationals is equal to the cardinality of
>the integers, while the cardinality of the reals is greater.
>They are all precisely defined and the results are provable.
>How do you define the infinities you talk about for a cipher
>and multi-cipher, and what is your proof that they are not
>the same?
This is a classic instance of your deliberately slanted logic. It is
just embarrassing. You really have no shame at all.
For those still with us, it is false to reason that a cipher alone
must be just as secure as that cipher with added levels of security
simply because there is no proof for either. We do know some attacks,
we do know that those attacks are complicated or eliminated by some
additions, and if we have those additions, we have strengthened the
cipher against those attacks. And the additions often function
against whole classes of attacks.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 9 Feb 2000 23:38:17 -0800
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> It is clear to me that you think all we need to do is have some
> academics check out candidate ciphers (even though we really don't
> know how much effort anyone in particular has put into doing that),
> then society should use the result.
Terry, it seems to me that your statement is primarily subjective in
nature: You are not personally comfortable with the level of assurance
provided by the AES candidates.
That's perfectly fine. Indeed, figuring out what level of assurance
we are each comfortable with surely requires a necessarily subjective
and personal assessment. But I hope we can agree that this is an issue
that reasonable people can rationally disagree on [*], and no matter how
much we discuss it back and forth, it is unlikely that we will come to
any widespread agreement. Fortunately, we need not all agree.
Perhaps it would be more productive to discuss the science: if we find
ourselves in a situation where we are unhappy with the assurance level
offered by the available cryptographic primitives, what techniques will
be most effective for remedying that situation?
You've already suggested multi-ciphering as one possibility. How does
that compare to just bumping up the number of rounds by a corresponding
amount, without introducing heterogenous round structures? How does that
compare to "frequent re-keying" techniques, a la those advocated by John
Savard on this forum (and others elsewhere)? What other possibilities
are there? What metrics might one use to assess the merits of the
competing proposals?
Just a suggestion. I'm curious to hear your thoughts, but as always,
feel free to ignore this post if you don't find it useful.
-- David
[*] Of course, if anyone relies on faulty logic in coming to their
judgement, it is only kindness to point out flaws in their logic, but
that's a special case.
------------------------------
From: "Matias C. Szmulewiez" <[EMAIL PROTECTED]>
Subject: parece que me colge
Date: Thu, 10 Feb 2000 04:27:14 -0300
Como estas amor.. ahhh te extra�o asi que aca toy de vuelta molestando
:) como veras me colgue de vuelta aca en sinectis... y bue.. pero eso si
antes de las 5 me rajo seguro : )
Che llamame ok... ahhh y sabes que te amo mucho no??? bue sabelo.. sos
la mujer mas ermosa y lo que mas me gusta de vos es que aparte de
atraerme oviamente ficicamente me encantas vos.. vos como sos
realmente... tu forma de ser es la que me encanta... te amo bebe...
espero que no cambies nunca ya que sos demaciado especial... bue basta
de alagos porque sino te agrandas o quisas hasta te cansas jajajaja....
bue te dejo y te mando besos infinitos : *
Te amo con toda mi alma
Tu hombre
Matias
--
Cordialmente.
Mat�as C. Szmulewiez
Soporte T�cnico
Sinectis S.A.
Bs. As. - Argentina
------------------------------
From: "Lassi Hippel�inen" <"lahippel$does-not-eat-canned-food"@ieee.org>
Subject: Re: micropayments and denial of service?
Date: Thu, 10 Feb 2000 08:02:54 GMT
[EMAIL PROTECTED] wrote:
>
> What effect would micropayments have on denial of service attacks?
>
> If a request comes without a payment, there's no need to respond.
> There's still a need to read the request and verify the payment -- maybe
> this alone is enough for denial of service attacks?
Many attacks use brute flooding at the lower levels of the communication
network. You don't have enough time to check the existence of a payment,
because more and more requests are coming in.
> If a request comes with a valid payment, the payer would reach their
> spending limit pretty quick, which should motivate compromised sites to
> uncompromise themselves. I understand that denial of service attacks
> are usually done indirectly through compromised sites.
Checking the validity requires a cryptographic operation, which in the
case of electronic money isn't trivial. It would be easier to use IPsec
authentication headers. They have been designed for the purpose.
> (I grant you that requiring payments is probably suicide for an online
> business whose competitors allow anonymous free access. And I'm
> fond of being an anonymous free user myself.)
Agreed.
> So, what effect would micropayments have on denial of service attacks?
>
> - Bob Jenkins
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
IMHO, nothing that IPsec cannot provide easier. Which leads to another
can of worms: why isn't IPsec in wide use?
Some reasons off the cuff:
- there is no working globally accepted PKI (same for micropayments)
- authentication spoils the fun of anonymity
- IPv4 doesn't have IPsec support by default
- it doesn't have enough addresses either -- and hacks like NAT don't
mix well with IPsec AH
-- Lassi, an IPv6 evangelist
------------------------------
** 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
******************************
