Cryptography-Digest Digest #849, Volume #13       Fri, 9 Mar 01 21:13:01 EST

Contents:
  Re: Encryption software (Paul Rubin)
  Re: Safe to use DSS key for DH? (Peter Gutmann)
  Re: PKI and Non-repudiation practicalities (Peter Gutmann)
  Re: PKI and Non-repudiation practicalities (Peter Gutmann)
  Re: => FBI easily cracks encryption ...? (Matthew Montchalin)
  Re: Applications of crypto techniques to non-crypto uses (John Savard)
  Re: => FBI easily cracks encryption ...? (Paul Rubin)
  Re: Q: Help needed -- reverse-engineering  ("Douglas A. Gwyn")
  Re: Q: Tempest Systems ("Douglas A. Gwyn")
  Re: Tempest Systems ("Douglas A. Gwyn")
  Using SHA as a checksum... ("Moritz Voss")
  Re: PKI and Non-repudiation practicalities (those who know me have no need of my 
name)
  Digital enveloppes (br)
  Re: Encryption software (those who know me have no need of my name)
  Re: One-time Pad really unbreakable? ("Douglas A. Gwyn")
  Re: Super strong crypto ("Douglas A. Gwyn")
  Re: Super strong crypto ("Douglas A. Gwyn")
  Re: Super-strong crypto......................(As if). ("Douglas A. Gwyn")
  Re: Text of Applied Cryptography ([EMAIL PROTECTED])
  Re: Meaninog of Kasumi ("Scott Fluhrer")
  Re: Super strong crypto (David Wagner)

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

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Encryption software
Date: 09 Mar 2001 16:12:32 -0800

"Henrick Hellstr�m" <[EMAIL PROTECTED]> writes:
> I haven't heard much but complaints about PGP from ordinary end users. They
> find it too complicated, and don't like to mess with the security issues
> involved in exchanging public keys with others. Someone ought to be able to
> design an application better than PGP in these respects.

I agree with this, though the PGP integrations with MS Outlook and
similar programs are reasonably easy to use.  I do think PGP
inconveniences users too much for the sake of stopping MITM attacks.
Those attacks aren't an important threat in most current situations.
That may change in the future of course.

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

From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Safe to use DSS key for DH?
Date: Sat, 10 Mar 2001 00:13:28 -0000

lcs Mixmaster Remailer <[EMAIL PROTECTED]> writes:

>Suppose you have a DSS key, of typical size: prime modulus p of 1024 bits,
>generator g generating a subgroup of size q, where q is 160 bits.

>Would it be safe to use this key for DH and/or ElGamal encryption?
>Would you still get ~80 bits of security (based on the modulus size)?

This is pretty much what the (indefinitely-delayed) X9.42 DH standard does,
it's safe provided you take the usual precautions (make sure the exponent size
is appropriate for the prime size, use something like Lim-Lee key generation,
etc etc).

(DSA seems to have become the cargo cult source for key generation whenever any
 standards group considers a DLP-based PKC, it's now used for DSA, KEA, and
 X9.42 DH even though it's not really needed for that).

Peter.


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

From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: PKI and Non-repudiation practicalities
Date: Sat, 10 Mar 2001 00:22:08 -0000

Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:

>i would have said that public/private key authentication does a little
>bit better job than secret-key/pin authentication .... since it
>eliminates some issues with the sharing of a secret-key.

It can be argued that a PKI-based authentication scheme is *less* secure than a
straight password-based scheme, for at least two reasons:

1. A PKI typically results in a parallel trust/authentication infrastructure
   which has to be built alongside the existing one.  To stop a user with a
   password, you lock their account.  To stop a user with a cert, you contact
   the CA which issued it and ask them to revoke it and hope they're open for
   business at 3am when you discover the problem and hope that whatever
   application relies on the PKI bothers to do CRL checks and hope that...

2. The typical end user is going to be running Windoze and using the name of
   their dog as the password for their private key.  With a decent challenge-
   response-password-based system you can lock an attacker out after n
   attempts.  With a cert-based system, the attacker can suck the encrypted
   file off the end user's machine using the MSIE security hole du jour and try
   dog names in the comfort of their own home until they get the right one.

Those are just two sample scenarios to illustrate that replacing passwords with
a PKI isn't quite the universal elixir it's been sold as, you need to think
very carefully about the implications of what you're doing before you deploy
one or the other.

Peter.


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

From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: PKI and Non-repudiation practicalities
Date: Sat, 10 Mar 2001 00:23:36 -0000

[EMAIL PROTECTED] (Vernon Schryver) writes:

>In the spirit of that last sentence, judging from current practice,
>the weakest link is in associating the secret or whatever with the
>entity to be authenticated.  The Verisign and Thwate systems for
>authenticating you when you submit a key to be associated with a domain
>is not exactly strong.  The cost for a bad guy to pretend to represent
>any except one of the Fortune 50 is surely not much more than the cost
>that Verisign charges for a year of PKI service.  It's not as if a
>Dun & Bradstreet DUNS number or "articles of incorporation, partnership
>papers, business license, or fictitious business license" are unforgeable
>or even difficult to forge proofs of identity.

Thus the Matt Blaze quote from RSA2K:

  "A commercial CA will protect you from anyone whose money it refuses to take"

Peter.


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

From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto,us.misc
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 9 Mar 2001 16:20:29 -0800

On Fri, 9 Mar 2001, Jim D wrote:
|You need to be much closer than that. A few tens of metres. 
|The inverse square law applies to the radiation, which isn't
|particularly strong to start with.

Most people think of 'shielding' as something that is stationary,
like a window screen made of fine wire mesh.  Is there any advantage
to having a moving, swiveling, or jiggling screen, I mean, in
addition to grounding it, or controlling its valence or charge
in response to the approaches of a magnet at the end of a pendulum
that has been set in motion manually?   Lots of us have fans, and
stepper motors, and power supplies that can be put to use, you
know.  :)

How does a typical US embassy get around to shielding its own
computers?


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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Applications of crypto techniques to non-crypto uses
Date: Sat, 10 Mar 2001 00:24:17 GMT

On Fri, 09 Mar 2001 23:51:16 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:

>Are there other known applications of crypto techniques to 
>non-crypto uses? Thanks.

Well, modems avoid long runs of 1s or 0s by XORing the data with the
output of a shift register.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

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

From: Paul Rubin <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: 09 Mar 2001 16:45:09 -0800

[EMAIL PROTECTED] (Damian Kneale) writes:
> I'm not that confused.  Codebreaking comes in several stages, the
> first of which is just finding the relevant code.  Diplomatic codes
> tend not to be standard ones, and just finding it can be fun by all
> accounts. 

What accounts?  The American Black Chamber?  Sorry, but this isn't the
1930's any more.  Do you have some more modern accounts of codebreaking
at that level?  Post-1980, say.

> Once you have that, you do the key cracking or recovery.  Its hard,
> but not impossible.  If it weren't possible, virtually every western
> government wouldn't have sigint agencies.

I know this is hardly ironclad evidence, but at a panel discussion on
cryptography exports at the RSA conference a few years ago, all
present seemed to agree that the sigint cryptanalysis is basically
over.  That's why U.S. attempts to control encryption these days is
driven mostly by domestic law enforcement (the FBI), not the NSA as
previously.  The sigint agencies know the score by now.

> I'd bet you _all_ your lifetime earnings that at least some government
> level codes are crackable.  Even a 5-10% success rate is a good
> success rate in terms of giving a picture of ongoing activities. 

I don't believe for one second that 5% of encrypted diplomatic traffic
is cryptanalyzable by anyone.

> >Do you seriously think the enemy (either an enemy in a war, or a
> >terrorist, or even an ordinary criminal) is going to obey the
> >regulations?
> 
> Not at all, and do you think that the NSA are about to admit that they
> can listen in to (as a random example) Japanese Diplomatic codes, but
> not naval codes?  Or that France has better encryption and key
> generation than Spain? 

Again, you're pretending the present situation is comparable to
WW1/WW2 and things aren't like that now.  For example, the new edition
of Kahn's "The Codebreakers" has a chapter at the end, which claims
that the battle between cryptographers and cryptanalysts (that the
book chronicles) is now over--because of computers, the cryptographers
have won.

> Legislation to make a job easier is a long way from proving it
> cannot be done.  The recent report to the European parliament would
> tend to imply otherwise, if you believe the findings.

What report is that, and what do the findings say?

> >If not, exactly what is left for the regulation supposed to protect
> >you against?
> 
> Ask instead what the government wishes to know.  I don't recall any of
> this sort of legislation being justified as helping the individual,
> instead if helps "society" or "the country".  

Ok, how are those regulations supposed to help society or the country?

> If you truly believe code breaking isn't possible for good codes,
> why resist the trend to legislate?  Just use PGP and trust your keys
> (give false ones if you have to - at least you'll know when you are
> being investigated, as someone will have to knock on your door to
> tell you that yours keys are "out of date" - that will of course be
> your excuse!).

Because I don't want to get locked up for encrypting my email or for
writing cryptography programs.  

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: Help needed -- reverse-engineering 
Date: Sat, 10 Mar 2001 00:01:56 GMT

Vlad ROMASCANU wrote:
> What tools can I use to analyze this beast?

Fourier analysis of the delta stream shows a strong 32-bit periodicity.
If you chunk the data into 32-bit words (big endian), the difference
of the all-0 and count-by-N delta streams (same as the deltas of the
difference) are all divisible by N.  The count-by-N sequence 32-bit-wise
delta streams have the same lower 9 bits in each word for the same
sequence.  The octet-wise delta stream for the all-0 output is
a5 69 5a 96 ... (repeating) the bit patterns of which strongly suggest
a balanced mask intentionally chosen by the designer.

I think there must have been an error in the results for 00 01 02 03 ...
and 00 01 03 04 06 07 ... since you said they had identical outputs.

To make further progress I'd suggest some non-periodic tickling
experiments; e.g. compare 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
with 00 00 00 00 01 00 00 00 00 00 00 00 00 ... and similarly for
other single-bit positions in the input stream.  (Impulse functions.)

The data you presented seems to have started at some "reset" state;
after a reset, do you *always* get the same outputs when you provide
the same input sequence?

An interesting puzzle..

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: Tempest Systems
Date: Sat, 10 Mar 2001 00:07:00 GMT

Frank Gerlach wrote:
> Transmitting the same signal multiple times can also be considered FEC.

Yes, it's redundancy that can be used to pull signal out of noise,
and that is in fact what is exploited by monitoring vans etc.
But it wasn't specifically designed for that, so the coding gain is
lower than if it had been so designed.  (If JPL's deep space probes
had merely repeated the data instead of using a more clever FEC
code, it would have significantly reduced the effective throughput.)

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Tempest Systems
Date: Sat, 10 Mar 2001 00:12:12 GMT

Frank Gerlach wrote:
> Mok-Kong Shen wrote:
> > Couldn't one create noise with some appropriate generators
> > to defeat monitoring?
> Very difficult, because the noise is added additively, unlike a stream
> cipher, which uses a nonlinear function like XOR. This means that you
> can simple average out the noise, if the signal is sent multiple times
> (as with a lot of computer signals).

I don't know what you meant about the tsream cipher, but a clue
to the jam resistance is that Gaussian noise adds like the square
root of the number of frames while the real signal adds linearly,
so if you collect enough frames eventually the accumulated signal
stands out from the noise.  There has, however, recently been an
invention wherein the display signal itself is dithered in order
to suppress its frame-to-frame correlation while still remaining
legible.  There's a paper on it somewhere but I forget where.

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

From: "Moritz Voss" <[EMAIL PROTECTED]>
Subject: Using SHA as a checksum...
Date: Sat, 10 Mar 2001 02:23:48 +0100

Okay, I've been playing around with Python a little, and it has these really
easy-to-use cryptographic services.

Apart from working out passwords, I wondered whether it's a good idea to use
SHA as a checksum for (small) text files... ? I'd say it certainly
outperforms a 32bit CRC, doesn't it?

In fact, this is for a security issue, I'll have a small script or data
block, and need to see whether it is the same, or has been tampered with,
and in that case, it will be updated with the original.... instead of
sending some thousand bytes in vain, I'd  just prefer to send the digest of
the python sha object....compare that, and move on.

Or is this a taboo thing to do?

--
--
Moritz "Thygrrr" Voss
http://www.thygrrr.com







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

From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: PKI and Non-repudiation practicalities
Date: Sat, 10 Mar 2001 01:17:32 -0000

<OEcq6.505$[EMAIL PROTECTED]> divulged:

>The AADS model can allow the individual to generate their own
>keys/certificate - 

can allow, but do you really expect the banking industry (to name but one i 
think likely to object) to accept it?

and for those without "additional" means of generating a new secret it 
still means an extended delay before they are again able to conduct 
transactions.

further, while your description is slightly different than mine, you still 
describe exactly what i did, to wit, you are without access to the 
materials or services controlled by the compromised secret until the 
replacement is generated and communicated to all linked institutions.  
granted each material or service becomes available as the associated 
institution is notified, so that you can sequence according to need vs 
convienience.  but that still leaves quite a lot of work to do to get it 
all done.  (i don't like most of those credit card "registries" as it is, 
and it looks like aads would make them almost a necessity.)

i also missed what the expected mechanism is to properly certify that you 
are the correct party to declare a particular secret as compromised, 
especially in anonymous (cash-like) situations.

>This is what you do now with a wallet full of cards, 

taken for a moment to be credit/debit card only:  only if i lose the entire 
wallet.  leaving one card somewhere means a single call, and leaves me with 
the utility of all the remaining cards.  and it has, in general, no effect 
at all on my ability to access my various accounts, perhaps via the 
internet.

i'm not against aads, at all.  in fact i think i like it quite a bit.  but 
there seem to be issues that have yet to be fully explored, e.g., unless 
each institution or anonymous situation is (or can be) provided with 
different "public" secret the potential for abuse of privacy is huge.

-- 
okay, have a sig then

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

From: br <[EMAIL PROTECTED]>
Subject: Digital enveloppes
Date: Fri, 09 Mar 2001 20:19:32 -0400

I have invented a digital enveloppes where you may put any plain text
and send it.
What I have to do to patent it?

Thank you for your kelp

BM

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

From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Encryption software
Date: Sat, 10 Mar 2001 01:30:59 -0000

<98br4c$c50$[EMAIL PROTECTED]> divulged:

re: pgp

>They find it too complicated, and don't like to mess with the security
>issues involved in exchanging public keys with others. Someone ought to
>be able to design an application better than PGP in these respects.

microsoft did just that in outlook express (and even outlook 2000) -- or at 
least came closer.  i'm don't think their cure is worth it.

-- 
okay, have a sig then

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Sat, 10 Mar 2001 00:34:51 GMT

Mok-Kong Shen wrote:
> "Douglas A. Gwyn" wrote:
> > Determinism can still involve random processes.
> Could you please elaborate your first sentence?
Not without a long discourse on the meaning of determinism
in the philosophy of science.  Determinism, causality, and
nonrandomness are similar but technically all different.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 10 Mar 2001 00:40:30 GMT

Let me put it this way:  You don't need guardrails on mountain
roads if nothing will go wrong, but highway engineers generally
add them as a safety precaution *against a foreseeable class of
contingencies*, even though it costs something to do so.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 10 Mar 2001 00:50:12 GMT

Mok-Kong Shen wrote:
> Could you please clearly point out ...

I recently commented on (2) and refer you to that.
Otherwise, I'm going to resist the bait.  I don't
care whether your alternative schemes are better
or worse, just that you're giving these issues more
consideration than has traditionally been done.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super-strong crypto......................(As if).
Date: Sat, 10 Mar 2001 00:57:18 GMT

"Henrick Hellstr�m" wrote:
> Hijack the message ... Then ..., and send that to the user.

Oh, okay.  Most actual OTP uses don't provide a scenario
that can be exploited in that way.  I thought maybe it
was supposed to be an eavedropping-based attack.

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

From: [EMAIL PROTECTED]
Crossposted-To: alt.anonymous.messages,alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography
Reply-To: *
Date: Sat, 10 Mar 2001 01:44:26 GMT

On Fri, 9 Mar 2001 17:31:37 -0500, "Ryan M. McConahy"
<[EMAIL PROTECTED]> wrote:

>I am _not_ a troll! If I can't find it from you, I'll find it somewhere
>else.

Enjoy. Might not be the newest but it is all out there.
Courtesy of the authors.

Handbook of Applied Cryptography
  http://www.cacr.math.uwaterloo.ca/hac
Applied Cryptography: Schneier
  http://134.155.63.117/quantico/TE/appliedcrypto.zip



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

From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Meaninog of Kasumi
Date: Fri, 9 Mar 2001 17:37:51 -0800


Arturo <aquiranNO$[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 8 Mar 2001 13:30:01 -0800, [EMAIL PROTECTED] (Gregory G Rose) wrote:
>
> >In article <[EMAIL PROTECTED]>,
> >Mike Rosing  <[EMAIL PROTECTED]> wrote:
> >
> >"Kasumi" means "fog", and the name is derived (as
> >is the algorithm) from MISTY.
> >
> >Greg.
>
> It is?  I read Kasumi (I mean the algorithm) is a derivation from
> Rijndael.

Huh?  They are both block ciphers, but there really isn't all that much
resemblance beyond that.

Rijndael is an SPN network which looks at the data as a rectangle of bytes.

Kasumi is a Feistel network, where the nonlinear function is itself a
Feistel network.

I am ignorant of the internals of MISTY, and so I cannot comment if Kasumi
is derived from it.  However, it is so different from Rijndael that any
relationship between them appears unlikely.

--
poncho




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

From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 10 Mar 2001 01:58:41 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)

Douglas A. Gwyn wrote:
>Let me put it this way:  You don't need guardrails on mountain
>roads if nothing will go wrong, but highway engineers generally
>add them as a safety precaution *against a foreseeable class of
>contingencies*, even though it costs something to do so.

Ok, so we're back to my original question.  We're willing to spend
a certain amount of resources (encryption speed, extra bandwidth,
whatever) to achieve higher confidence in our result.  We have a
whole series of possible defenses we could use.  For instance:
  (i)   Gwyn's super-strong crypto; or,
  (ii)  Triple the number of rounds; or,
  (iii) Use GGM's PRG-doubling, as I described previously.
How do we choose which one to use?  What methodology do we use to
evaluate the alternatives?  (This is a serious question.)

It also raises the following question.  I can imagine some criteria
and methodologies which lead one to prefer (ii) or (iii), but I have
a hard time imagining a methodology where (i) would be the preferred
alternative.  Can you help remedy my poor imagination?

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


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to