Cryptography-Digest Digest #301, Volume #11 Fri, 10 Mar 00 21:13:01 EST
Contents:
Re: Free-MAC mode (antirez)
Re: Q: Voice encryption (John Myre)
Re: ZIP format is gone in the past. (Onke M. Airly)
Re: Passphrase Quality ? (Frog)
Re: Free-MAC mode (David A. Wagner)
Re: encrypting to unknown public key? (David Hopwood)
Re: If we spent as much time.. (John Myre)
Help ("rosi")
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Crypto Patents: Us, European and International. (Terry Ritter)
Re: Crypto Patents: Us, European and International. (Terry Ritter)
testing ("leia")
Re: encrypting to unknown public key? (David A Molnar)
Re: Help ("Adam Durana")
----------------------------------------------------------------------------
From: antirez <[EMAIL PROTECTED]>
Subject: Re: Free-MAC mode
Date: Fri, 10 Mar 2000 23:47:42 GMT
In article <[EMAIL PROTECTED]>,
Adam Back <[EMAIL PROTECTED]> wrote:
> Following on from the discussion of block modes which try to exhibit
error
> propagation to give a MAC or MDC combined with a block mode in the
thread
> with subject "avoid man-in-the-middle known plaintext attack using a
stream
> cipher", here's a block mode Anton and I have been working on.
I'm using a similar joke in a stream cipher without feedbacks
in order to build a MAC without a secret. Just I append to the
message M, 20 random bytes and the SHA1(M, 20 random bytes).
This should be safe even if the attacker known M, comments?
--
antirez
email: antirez@linuxcare dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Q: Voice encryption
Date: Fri, 10 Mar 2000 17:17:58 -0700
Mok-Kong Shen wrote:
>
> JimD wrote:
<snip>
> > Digital ciphony gives better quality and is much more secure,
<snip>
>
> I like to know whether there are reasons against using both
> techniques simultaneously.
"Digital ciphony gives better quality".
Doing both would require all of the bandwidth required by
digital, with the loss of quality of analog, and would cost
more. In other words, you get the worst of both worlds,
for more money.
And the only way that doing both would increase your
security is if the digital encryption was inadequate in
the first place.
<snip>
>
> Is it possible to use e.g. DES to encrypt voice?
Of course. Why not?
------------------------------
From: [EMAIL PROTECTED] (Onke M. Airly)
Subject: Re: ZIP format is gone in the past.
Date: Sat, 11 Mar 2000 00:22:21 GMT
"finecrypt" <[EMAIL PROTECTED]> wrote:
>It's more and more people prefer to use self-extracting executables instead
>of zip archives.
Absolutely not! I'm generally very reluctant to run any EXE file that I
don't trust. I much prefer to unzip a file and examine the contents first.
--
"Onke M. Airly" is actually 4623 159807 <[EMAIL PROTECTED]>.
0123 4 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Frog <[EMAIL PROTECTED]>
Date: 11 Mar 2000 00:25:46 -0000
Subject: Re: Passphrase Quality ?
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
On Wed, 08 Mar 2000, [EMAIL PROTECTED] (Ian L. Romkey) wrote:
>John Underwood <[EMAIL PROTECTED]> wrote:
>Seriously, all my system <http://www.5x5poker.com/grid/> does is give you
>the option of destroying your password so that not even you can ever
>recover it. In most real-world cases, there's no actual risk of torture or
>even legal prosecution, particularly if you're prepared to demonstrate how
>the system works and show that there's absolutely nothing that you can do
>to help recover the password. It never hurts to keep your options open.
>
Sorry about the binary - but it's smaller than some of these long winded posts.
just a small zipped excel spreadsheet that calculates a random grid
(http://www.5x5poker.com/grid/), it has a macro but this is just a copy and paste (I
recommend you disable macros - until you have a look to see for yourself). Thought it
might be useful for any one interested in the grid method.
cheers big ears
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Free-MAC mode
Date: 10 Mar 2000 15:49:20 -0800
In article <8ac1it$90l$[EMAIL PROTECTED]>, antirez <[EMAIL PROTECTED]> wrote:
> I'm using a similar joke in a stream cipher without feedbacks
> in order to build a MAC without a secret. Just I append to the
> message M, 20 random bytes and the SHA1(M, 20 random bytes).
> This should be safe even if the attacker known M, comments?
As in every other MAC-without-a-secret scheme I can think of,
chosen-plaintext truncation attacks allow forgery with your scheme.
See my post on Free-MAC, and change what needs to be changed.
------------------------------
Date: Fri, 10 Mar 2000 22:56:38 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: encrypting to unknown public key?
=====BEGIN PGP SIGNED MESSAGE=====
"David A. Wagner" wrote:
> On first glance, this looks like it may be related to proxy signatures.
> Have you checked out Blaze and Strauss's work on the subject?
>
> It also seems that a basic Diffie-Hellman (or El Gamal) encryption scheme
> can perhaps be adapted to your requirements. In the usual version of
> such a scheme, we fix a global generator g, and A's public key is g^{x_A}.
> I suggest that each party should choose their own generator g_A randomly,
> and publish (g_A, g_A^{x_A}) as their public key. The encryption of a
> message m is (g_A^r, E((g_A^{x_A})^r, m)) where E() is some combining
> function (multiplication in El Gamal, but a symmetric-key cryptosystem is
> probably better.) Then a public key (u,v) may be blinded by choosing b
> at random and letting the blinded public key be (u^b,v^b). Assuming that
> we work in a prime-order group where discrete log is hard and the
> Decisional Diffie-Hellman problem is infeasible, everything should be
> secure, I think.
A stated requirement was
# The blinding function B() "looks random" - it should be
# infeasible to guess any other BK or any other F given one
# (BK, F) pair. It should be infeasible to create another BK
# or another F given only BK but not the original PK.
The DH-based scheme above doesn't fulfil that requirement, because if
(u^b, v^b) is a public key, then so is ((u^b)^b', (v^b)^b'). I can't
immediately think of any way to fix that; it seems to be quite difficult.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMl9ZTkCAxeYt5gVAQHOvgf/RJwavkh1Qh3n62AgkUFS4PH2gOYJdquo
8E+N6e3TEUi1IHifZFPpOtZOh8q6DQ5mrXcU8fzT8P42mvxXzXd4GRUKaTJN6Z4l
pwPgi/3LV9cpi+HP0OXG8Cz5KjjGNjrxo+Wx/pPmQOui1CireI27j+P5LF3+aatx
xu3fc4XvxzNwleRlKnw/oTAXy0aM+xsNuYKwcn/xOf6Xgwgatn0aUsgPKK/Vk4F5
89wqssZqFI08GY3rVMOuqD+Q6If4LyWfHUhvMN0WwYAf1x5NOi93SxhayAndXMIs
cZwgjvEbjslchNcatzki7yr3GTKrtce81I62ytNTYI9+MQIxHoAIVQ==
=e3/f
=====END PGP SIGNATURE=====
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: If we spent as much time..
Date: Fri, 10 Mar 2000 17:29:19 -0700
"Steve A. Wagner Jr." wrote:
>
> If we spent as much time studying crytography and trying to crack and
> improve the most respected and current crypto algorithms, we'd have much
> more secure alternatives for the future. Instead, everyone wants to
> sport a unique cipher with their name on it.
Perfectly true, and worth stating now and again. On the other
hand, it's like saying, "if only people weren't so short-sighted
and selfish, the world would be a much better place." Umm -
right...
John M
P.S.
(Did you notice Bob Silverman's post on the Cipher Contest
thread? The one where he suggests spending time analyzing
AES candidate(s)? About the same, with approximately zero
response. Really, anyone who could do a durn thing about it
doesn't need to be told.)
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Help
Date: Fri, 10 Mar 2000 20:41:29 -0500
Hi,
I would appreciate it if people can tell me how to fix
a problem with reading the postscript paper of Client
Puzzle Protocol. I know nothing about postscript and
seem to get error each time I tried to go from page 4
to page 5. Thanks in advance.
Besides I would also like to finalize my consideration
of the 'Breakwater Protocol', a partial solution to the
flooding attack problem. If anybody can provide pointers
to art that might help in this direction, I would appreciate.
If anybody has any interest in a bit of mental exercise
and in contributing to such a protocol, ideas, protocol
design analysis, etc., I would like to work with him/her.
Ideas like the one proposed in 'Free services with tokens/
puzzles' will be great. Of course, as a side note, we
probably would like to avoid getting into the messy
area of 'trusted' (and only take that approach if nothing
else works.) Besides, I would like to keep it as simple
as possible.
I would like to get something, if at all possible, to have
overhead under 40 operations, and below thirty or twenty
would be even better. Not sure if achievable, just want to
have a try. (The number is for responding to a request
and rejecting an invalid request, each. I allow the full validation
of a legitimate request to be about a hundred operations
or perhaps a bit more).
Other properties may need be included: attacker can
not fool a client into doing anything for him, (virtually)
resitent to replay, etc.
Please let me know if you are interested (by replying to
this post, or by e-mailing me at [EMAIL PROTECTED], or both).
Looking forward to hearing from you.
--- (My Signature)
P.S.
If you have any comments about the CPP protocol
(assuming you have read the entire article), I would also
like to hear.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 11 Mar 2000 01:26:41 GMT
On 10 Mar 2000 22:35:26 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (D. J. Bernstein) wrote:
>Terry Ritter <[EMAIL PROTECTED]> wrote:
>> Feistel ciphers generally repeat *the* *same* functional rounds
>
>Nonsense. Each round is a different function.
>
>``But they're all so similar---the same algorithm with some key bits
>plugged in,'' you say.
>
>Wake up: _every_ computable function can be expressed as a single
>universal algorithm, called a ``universal Turing machine'' or an
>``interpreter'' or a ``circuit simulator,'' with a program plugged in.
The cryptanalysis of ciphers has little or nothing to do with the
ability to create an arbitrary transformation between plaintext and
ciphertext, and everything to do with the mathematical structure
between different parts of that transformation. It is that structure
which is sought, and when found, opens up the rest of the cipher.
There is always some structure, and it is always related to the
generating system, but a system which depends upon the repeated
application of similar operations is likely to have more and clearer
structure than some of us might want.
>The only question is what distribution of programs to select as keys,
>given a limit on encryption time. We know that the uniform distribution
>is horribly weak, at least for typical encryption times. A uniform
>random 16-round Feistel cipher appears to be much stronger than a
>uniform random circuit of the same size, and has much lower entropy.
>Further restrictions appear to add even more strength.
First of all, you clearly have no idea what practical "strength" is.
Strength is not about what you or your friends can or cannot break.
Strength is what the opponents can do, and you can never know that.
Next, the whole point of not using a uniform distribution of ciphering
programs is to get better designs than one would have at random. I do
not advocate using randomly designed ciphers; I advocate using well
designed ciphers at random.
>(It would be a massive surprise if all low-entropy distributions were
>weak. This would imply that integer factorization and many other famous
>problems can be solved very quickly.)
The issue is not entropy per se (although we do need at least 128 bits
to prevent brute force attacks on keys). Instead, the issue is the
structure in the transformation.
>> Whatever "simpler, faster"
>> function you like can be one of the three ciphers in a cipher stack.
>
>There's no reason to believe that this is better than using three times
>as many rounds in the same cipher.
Sure there is. We do not arbitrarily modify cipher designs because we
"think" they might be stronger with more rounds. We use the ciphers
as designed and go on from there.
>Strength comparisons are bogus when
>they ignore cost.
But strength comparisons are even *more* bogus if we cannot *measure*
strength. (Hint: We can't.)
>(Cost comparisons are equally bogus when they ignore strength. There are
>many papers that say ``look how fast this MAC is!'' when the MAC can be
>completely broken by an attacker who sends a few billion bytes of data.)
I agree.
>> And given a reasonably modern computer, that cost is rather small.
>
>I disagree. If I have a 500MHz computer receiving 10 megabytes/second
>of data, I only have 50 cycles to spend on each byte, and quite a bit
>of that is taken up by non-cryptographic processing. Speed is essential!
Well, I do have a 460MHz computer, but I don't receive email at
10MB/s. Nor do I care whether my email is ciphered in real time.
For end-to-end ciphering applications (such as email), plenty of
cycles are available for multiciphering. If some applications need
faster or real-time ciphering, then, clearly, they may not be able to
have the security of multiciphering. There is no silver bullet. But
we still have a fundamental problem:
Since we cannot prove any cipher secure, and cannot measure the
strength of any cipher, and cannot know what our opponents can do, how
can we trust any particular cipher?
In fact, we *know* that if our cipher *is* broken it will *remain*
broken as long as we continue to use it. The only way we can recover
from a broken cipher -- and we have no way to know when that is the
case -- is to *change* to a different cipher. To do that we need
multiple ciphers, and the ability to change ciphers.
If some application really needs fast ciphering (and thus ciphers
which are less certainly strong), then so be it.
---
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: Crypto Patents: Us, European and International.
Date: Sat, 11 Mar 2000 01:27:31 GMT
On Fri, 10 Mar 2000 23:09:18 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt Eric Lee Green <[EMAIL PROTECTED]> wrote:
>[...]
>Apparently
>IBM took advantage of a loophole that allows waiting up to a year between
>inventing something and applying for a patent on the invention.
That's not really a loophole, that is well-known law. In fact, I
doubt anyone really wants the alternative. If someone could not
publish without losing patent rights, there would be even more
potential for abuse in the period between inventing and mailing the
finished formal application.
>Note that this
>allows someone less scrupulous than IBM to look around, see a promising new
>(but unpatented) innovation, then file for a patent on that innovation,
>claiming that they had it first but simply did not file for the patent until
>11 months had passed.
Normally, patent attorneys are involved in patent applications, and
knowingly testifying falsely this could ruin their careers and lives.
It would also put them at the mercy of their client, or anyone else
who knew the real situation.
The few individuals who deal with the PTO directly are continually
warned about the penalties for perjury. But the issue does not
normally arise, because most applications depend only upon their
filing date, or perhaps a publication date which is fairly
incontestable. Only when there is an "interference" does the issue of
provable invention dates arise, and an interference is a complex
procedure which cannot be handled without a patent attorney anyway.
So in this case the outcome would be influenced simply by not having
enough money to fight, but there is nothing unusual about that in our
legal system.
>Note that IBM has not enforced their patent in the specific case of Electric
>Fence, and more than 5 years have passed, so Electric Fence can no longer be
>prosecuted as a patent violation.
As far as I know, the patent holder is not required to enforce the
patent, and the patent applies as long as it remains a valid patent.
>Also note that this does not stop IBM from
>enforcing the patent in other situations -- under patent law, you can lose the
>right to enforce the patent FOR A PARTICULAR VIOLATION if you don't enforce
>your right within 5 years,
OK, that basically sounds like a statute of limitations sort of
procedural thing, which may well be the case.
>but the only way to lose your patent rights
>entirely is to have the patent nullified (such as, e.g., by demonstration of
>prior art by others). Patents are not like trademarks, which must be actively
>defended to remain valid -- patents remain valid for their entire 17 to 20
>year life span.
That sounds right to me, except that it normally takes several years
for a patent to issue, so 20 years is unlikely.
---
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: Crypto Patents: Us, European and International.
Date: Sat, 11 Mar 2000 01:28:07 GMT
On Fri, 10 Mar 2000 23:12:23 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt Eric Lee Green <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> prevented others from obtaining a patent on that very same idea. In
>> fact, patents can be applied for even after someone else's publication
>> of that idea, given witnesses and/or patent notebook records.
>
>There once was a 1-year-max period between time of invention, and time of
>filing. Do you know if that still holds?
I am not aware there ever was a specific limit. The inventor is
supposed to be "moving toward" filing until actually filing. It might
be reasonable, for example, to spend some time actually testing an
invention before filing (which thus casts the definition in stone).
It is normally *not* reasonable to put an invention on the shelf only
to take it out when somebody else publishes. There have been some
cases which seem to have had that effect, however, such as the guy who
invented lasers but did not patent until decades later.
>As for witnesses and/or patent notebook records, it's amazing that we don't
>have more illegally obtained patents than we do, given how easy it is to forge
>records and/or find witnesses willing to perjure themselves for money...
Well, there would be multiple witnesses, and each would know the
others were giving false testimony. Each of them would suddenly have
come into money. But only the first to accept a prosecution deal
would skate; the inventor, the attorney and the other witnesses would
all face serious consequences. I dunno, maybe it happens, but the
risks are great. We do depend that individuals will have some degree
of ethics. In the end, every legal proceeding is like that.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "leia" <[EMAIL PROTECTED]>
Subject: testing
Date: Fri, 10 Mar 2000 20:23:26 -0500
test
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: encrypting to unknown public key?
Date: 11 Mar 2000 01:24:15 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> # (BK, F) pair. It should be infeasible to create another BK
> # or another F given only BK but not the original PK.
> The DH-based scheme above doesn't fulfil that requirement, because if
> (u^b, v^b) is a public key, then so is ((u^b)^b', (v^b)^b'). I can't
> immediately think of any way to fix that; it seems to be quite difficult.
Argh. You're right, and so is John Myre. I will say right now that
I thought I was thinking of non-malleability when I stated this
requirement. That is, when we have ciphertexts, we generally want it to
be infeasible to create a new ciphertext just by applying some function
(other than the encryption function) to a current ciphertext we have.
I unthinkingly carried this over to the blinded keys situation. My
*sincere* apologies for the confusion.
Might as well play with the mistake, though :
IF you can somehow acheive this requirement, then it seems you can have
a situation in which parties are "marked" by which blinded key they use
to encrypt messages. This would be useful in the case of referrals,
for instance -- if Alice gives Bob a blinded key, and Carol later uses
the same blinded key, Bob and Carol may be linked. Alice knows she
gave the key to Bob, so she infers that Bob referred Carol to Alice.
This assumes, *contrary to what I had previously thought*, that someone
can distinguish encryptions due to blinded public keys from those due
to normal public keys. Otherwise the only way to carry out this linking
seems to be to actually interrogate senders as to what public key they
use.
So on reflection, there seem to be several choices at least we can make
about such a "blind encryption" scheme :
(btw, if my terms change from previous messages or if you have better
terms, please yell)
* "single-blinding" vs. "unlimited blinding"
Whether a blinding of a blinded key produces a valid
public key ("unlimited blinding") or does not ("single
blinding").
* Whether or not the sender knows he is using a blinded
public key. Is there a single E() which takes
both PK and BK, or are there separate E() for PK and
for BK?
* Whether or not the recipient *knows* a message was
encrypted with a blinded key. Is there a single D()
which takes messages encrypted with both PK and BK, or
is there a separate D'() for BK??
* Whether or not the party which created the blinded key
can determine which messages were encrypted with that
key. He can't necessarily see the content - he can just
see which used "his" value of BK.
This might be useful in case Alice is contracting out
work using both Bob and Carol as agents. Bob and Carol
give out blinded keys to customers. Then they can simply
sniff Alice's link to see how much of her traffic is
due to buisness that they brought in, but can't actually
read any of Alice's traffic.
Note that Bob and Carol may not even know that the other
exists.
This is different than the situation in which Alice creates lots of
different key pairs, because Bob and Carol can create (and possibly
track?) new keys without needing Alice's private key. At this point
we're very close to the paper on "Atomic Proxy Cryptography" David
Wagner mentioned. I have only skimmed it so far, but it explicitly
covers encryption and some ideas which look like this.
Thanks,
-David
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Help
Date: Fri, 10 Mar 2000 21:04:12 -0500
RSA's CCP is totally bunk. We talked about this a few days ago, you might
want to look for that thread. Anyway not only does CCP not solve the
problem, I can think of a few ways to use the protocol to make a DOS attack
even more effective. Theres nothing you can do to protect your networks as
long as they are connected to the internet. Well there is one thing, secure
every machine connected to the internet so they can't be used to flood.
Even with IPv6 and other "solutions", DOS attacks can still take place.
(Keep in mind you wouldn't have to forge anything if you had 100,000
machines sending data to a single machine.) I'd say get an ISP with loads
of bandwidth and a national or even international network, and have them
filter your traffic. That should make it a little bit harder for the
average moron to DOS you.
------------------------------
** 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
******************************
