Cryptography-Digest Digest #923, Volume #8       Mon, 18 Jan 99 03:13:06 EST

Contents:
  Re: Export laws (Stephen Darlington)
  Dumb Question: Relationship between RSA and Factoring (Dean Povey)
  Re: On the Generation of Pseudo-OTP (Patrick Juola)
  Re: file size of encrypted vs. unencrypted data (EKR)
  Re: Cayley-Purser algorithm? (Kent Briggs)
  SAMAG.com Contact (Brad Aisa)
  Re: On the Generation of Pseudo-OTP (R. Knauer)
  Trusts (Anonymous)
  Re: On the Generation of Pseudo-OTP (R. Knauer)

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

From: [EMAIL PROTECTED] (Stephen Darlington)
Subject: Re: Export laws
Date: Sun, 17 Jan 1999 22:15:33 GMT

On Sat, 16 Jan 1999 11:41:18 GMT, [EMAIL PROTECTED] (Bruce
Schneier) wrote:

>When someone (presumably outside the US) tries to download the file,
>he is not doing anything illegal.  (Unless, of course, he lives in a
>country that believes US laws apply on non-US soil.)  The owner of the
>website is exporting the software (we think...this has never been
>tested in court.  I believe he is not exporting, but that's just me.)

So if I download the Twofish source code from your site, your
responsible?! Even though you have those questions for me to
confirm I live in the US etc - if I lie your responsible? Very
strange.

Stephen J Darlington
Author of the addZIP Compression Libraries
http://welcome.to/addZIP


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

From: [EMAIL PROTECTED] (Dean Povey)
Subject: Dumb Question: Relationship between RSA and Factoring
Date: 18 Jan 1999 00:52:50 GMT

Okay, call this a dumb question but...

That the security of RSA is equivalent to factoring is only a conjecture, but
would it be fair to say that any method of recovering the private key is 
equivalent to factoring (as p and q can be efficiently computed from 
e, d and n).

--
Dean Povey,                             |  Email: [EMAIL PROTECTED] 
Research Scientist, Security Unit,      |  Phone: +61 7 3864 2799 
CRC for Distributed Systems Technology  |  Fax:   +61 7 3864 1282
Brisbane, Australia                     |  http://www.dstc.qut.edu.au/MSU/ 
--
Dean Povey,         | e-m: [EMAIL PROTECTED]     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

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

From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: On the Generation of Pseudo-OTP
Date: 13 Jan 1999 10:13:44 -0500

In article <[EMAIL PROTECTED]>,
Mok-Kong Shen  <[EMAIL PROTECTED]> wrote:
>R. Knauer wrote:
>> 
>> On Tue, 12 Jan 1999 12:02:06 +0100, Mok-Kong Shen
>> <[EMAIL PROTECTED]> wrote:
>> 
>> >>Absolute
>> >>assertions are possible if they are deduced from axioms by logical
>> >>rules.
>> 
>> >> Even that has been challenged on several fronts. In terms of axiomatic
>> >> formal systems, you run into Godel's Theorem. In terms of computation,
>> >> you run into Turing's Halting problem. And in terms of elementary
>> >> number theory, you run into Chaitin's Matematical Indeterminancy.
>> 
>> >What did you mean by 'challenge' relative to what I wrote?
>> 
>> The statement you made above has been challenged many times before.
>
>Please give a pointer to literature. I'll be interested to know more 
>of the issue.
>
>
>> 
>> The challenges to your original statement above are to be found in
>> such places that discuss Godel's Theorem, Turing's Halting Problem and
>> most recently, Chaitin's Mathematical Indeterminancy. For example, it
>> is not possible to prove the truth of the following statement using
>> formal axiomatic systems: "This statement is false."
>> 
>> Douglas Hofstadter's book, "Godel, Escher, Bach" (aka "GEB") is a good
>> place to start if you are interested in these kinds of issues. Also be
>> sure to see Chaitin's papers where things get really indeterminate.
>> 
>> He has an equation where it is impossible to decide formally if there
>> is a finite number of solutions or an infinite number for a given
>> single parameter of the equation. The answer to that question on an
>> case by case basis (by varying the parameter) is completely random.
>
>Ah. Now I see where you misunderstood me. To requote what I wrote
>above:
>
>  Absolute assertions are possible if they are deduced from axioms 
>  by logical rules.
>
>This means if you find a true absolute assertion then it must have 
>been deduced from axioms by logical rules.

Doesn't follow, I'm afraid.  I can make lots of true absolute
assertions -- "my coffee cup is full," for instance -- that are
not the product of logical deduction.

        -kitten

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

From: EKR <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: file size of encrypted vs. unencrypted data
Date: 17 Jan 1999 17:22:58 -0800

[EMAIL PROTECTED] (Bill Unruh) writes:
> In <[EMAIL PROTECTED]> Grant Karlin <[EMAIL PROTECTED]> writes:
> 
> >I am trying to determine what the change in the required bandwidth is to
> >send encrypted data (using standard SSL transactions) over a network
> >versus sending the unencrypted data.
> 
> The sizes should be very much the same, except for very short files --
> ie the overhead should only be a few bytes in negotiating the
> encryption. Encryptions take blocks of the file and produce equal length
> blocks (8 bytes for DES,3DES,IDEA,..., 1 byte for RC4 ) So if the block
> size does not correspond to a multiple of the length of the file, the
> file needs to be padded up to a multiple. And the length of the original
> file needs to be sent, and the encrypted symmetric key needs to sent. So
> maybe 100 bytes extra. (I am sure someone knows the exact figure for
> SSL)
It varies, but it's typically more like a K for negotiation, 
since SSL requires the certificate to be sent (from server to client).
Plus, there's between 1 and 8 bytes for block padding/per message
and 16-20 bytes of MAC.

-Ekr

-- 
[Eric Rescorla                                   [EMAIL PROTECTED]]

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

From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Cayley-Purser algorithm?
Date: Sun, 17 Jan 1999 16:33:43 GMT

[EMAIL PROTECTED] wrote:

> You MUST file at least a provisional application before publishing.  Once you
> file a provisional application you have a year to file the full application.
> But you can not publish first.

Was a provisional application filed for RSA before it was first published?  How
about Diffie-Hellman?

--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com



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

From: Brad Aisa <[EMAIL PROTECTED]>
Subject: SAMAG.com Contact
Date: Sun, 17 Jan 1999 21:18:43 -0500

=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1

Ralph Barker
Editor,
Sys Admin

Dear Mr. Barker,

I was extremely disappointed with the article "Password Encryption in
Shell Scripts" by Ed Schaefer (Sys Admin Jan, 99). I think it was really
quite galling of Mr. Schaefer to list Bruce Schneier's excellent and
authoritative book on cryptography as his one and only reference, given
that the only "reference" to this book was a citation properly
condemning Mr. Schaefer's encryption technique as an "embarrassment."

In essence, Mr. Schaefer is advocating a simple XOR cipher for
"encrypting" passwords for shell scripts. Well, maybe Mr. Schaefer
should bother to investigate WHY people like Bruce Schneier call such
techniques "embarrassing". 

There is a principle of security that states that really bad security is
*worse* than no security. Incompetently encrypting passwords in shell
scripts is *worse* than not encrypting them. The reason, is that no one
will likely put a password in the clear in a script, and thus will
attempt to create a protocol or procedure some other way. But with
pseudo-security, one gets a false sense of security, and proceeds to use
it. This opens one up for attack.

A similar situation obtains with regard to most password protection
schemes built into applications such as word processors. These are
typically very lame, cryptographically speaking, and some commercial
products even exist that specialize in cracking a wide variety of these
products. A person might not save highly sensitive information in a
document without such security, but if they are falsely duped into
thinking their password provides security, they may store highly
sensitive information. But the snooper can easily recover it using the
readily available cracker programs.

Remember, security is usually not needed for the honest. In today's
environment where so many computers are directly, or indirectly
connected to the world wide internet, and in which concerted attempts
are being made daily by crackers to break into systems to either steal
information or cause damage, it behooves system administrators to employ
professionally responsible, technically adequate security techniques.

Although I am not an expert in the area of cryptography, I do recall
reading discussions of simple techniques for securing passwords in 
scripts, and I'm sure there are techniques at hand that are as
straightforward as Mr. Schaefer's, while being cryptographically
adequate. 

- - --
Brad Aisa
[EMAIL PROTECTED]  -- PGP 5.0 public key available at:
http://keys.pgp.com:11371/pks/lookup2?op=index&search=0x6F053CE9

"Laissez faire."

=====BEGIN PGP SIGNATURE=====
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBNqKZ64AccBBvBTzpEQKevgCgguUJ23mlzHD7fVN3T4B+Q2Wc0YYAoM1n
8rcnYD5SBzzyD4m0KTLqjL9c
=uCPD
=====END PGP SIGNATURE=====

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

From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 19:03:01 GMT
Reply-To: [EMAIL PROTECTED]

On 12 Jan 1999 10:41:35 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:

>It's *always* possible to compress *some* outputs of any generator.
>However, if you can easily compress pi by a technque related to
>the base-16 generator, this means that not all substrings are
>equiprobable in all contexts.

I still don't see that. Please elaborate.

If I take the first 1,000 sequences from a TRNG, I can compress the
concatenation somewhat. The fact that the concatnation was not the
result of a digit expansion of pi should be irrelevant, unless there
is some particular property of pi that imakes it fundamentally
different from the concatenation of sequences from a TRNG.

But, if there is a fundamental difference, then pi is not random - so
we are back where we started.

Bob Knauer

"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe


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

From: Anonymous <[EMAIL PROTECTED]>
Subject: Trusts
Date: 18 Jan 1999 08:33:40 +0100

=====BEGIN PGP SIGNED MESSAGE=====

Hi all,

There's a real-time, non-aural secure chat program that
uses symmetric keys only. Now the makers are planning
to implement Diffie-Hellman key exchange mechanism, but
in a way which IMHO is crazy. I was wondering if any
of you out there could either confirm or deny my fears.

The makers are going to use DH-keys without any kind of
trust system whatsoever, no prior exchange of public keys.
They are going to generate a DH-keys _per_session_, and
use that to achieve keyexchange for the underlying symmetric
cipher. They claim that this is secure because it's
infeasible to spoof a TCP/IP session, ie mount a
man-in-the-middle attack by replacing the exchanged
DH-keys on-the fly. What do you guys think? Is it
infeasible? IMO it's quite easy to spoof such a session,
but could be wrong. Comments?

PGPfone uses biometrics (with the nice variant of
fingerprint concept) to ensure one key is used at
both ends of connection, but in this case there is
no additional security measures, just simple genning
of DH-keys and exchanging them. Is this secure?



And I'd got a question for Bruce Schneier, too:

In your book Applied Cryptography 2nd edition, on
page 50, you deal with public key exchanges with
dig sigs. My question is, am I correct in ascertaining
that the material therein is only the basic threat model,
and that any PK trust system should be designed to thwart
the scenario presented therein? Ie, making sure that if
the security of one signer becomes compromised, the
security of the trust model itself is not compromised?
In case of S/MIME this is achieved by making very sure
that the introducer is secure, but in the case of PGP's
deployed trust model, Web-of-Trust, there are other ways
of dealing with this problem. Am I correct?



Thanks,

- --EO


=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2

iQEVAwUBNqK+xnlLzQ4ghnFxAQEhXQf/YNOAeIcrpZXxrurFF4ROvsoD1Mrm105w
7Jd8is8m32xaywMI54LkTIxq7OzFq6zyIZpkJp+jtGlTDZ8HaafuR+bjXYkz7t7t
v/bvkl0NLRpo4GTk6p2ZyPYnAlnzFHWpeKywLGN9rG+6CvsLKpME/gG5HmRSmz6Y
uSHg5C4wKz68FjLQYUJEtDn1KFxOS/BN82XpkSrCkiSdb+uz7PwxrsuVtbzlYrNs
OrO0h8h736tcHX69wvLArw61pvWE6I0eapgXz/c/BwhMj1klMsv1vEwRmLkBWRfA
dd1PtpGSq1zuPqVCmVOQrGeDhZpmRiLzZj7WeqyfiOK/zm6ZN8SPdA==
=m4oj
=====END PGP SIGNATURE=====








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

From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Wed, 13 Jan 1999 20:07:19 GMT
Reply-To: [EMAIL PROTECTED]

On Wed, 13 Jan 1999 13:20:15 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:

>The catch is the fact that the size of the code has to be at least as large as the
>size of the sequence.

And therein lies the rub for most sequences. But for some, it is
conceivable that the complexity (size) of the algorithm is far less
than the size of the original number.

Let's say you wanted to buy something and you decided to pay

10000000 00000000 00000000 00000000

units of currency for it (just imagine hyperinflation).

That number has a unreduced complexity of 32 bits.

Now consider this algorithm:

for(i=0;i<32;i++) printf("1");

That code fragment has a complexity of log2(32) + C, where C is the
overhead of the for( ) loop.

log2(32) = 5, which is already a significant reduction over 32,
ignoring C for sake of discussion (C becomes small in comparison to N
for large N, and I did not want to clutter the example with a
kazillion 0s just to get around it).

Now all I need to do in order to communicate my intent to buy at that
price is transmit that code fragment to my correspondent, and he will
decompress it by running it on his computer, in which case he will
obtain a perfect reproduction of my original number.

>Consider this from the perspective of information theory.  In a binary sequence
>from a perfect TRNG the odds of the "next bit" being 0/1 are 50:50.  Thus each
>data bit represents one bit of information; 100% density.  If you could compress
>all such sequences, you would achieve a density greater than 100%.

I agree, but as one poster said earlier, entropy applied to sequences
does not have relevance to crypto. That is a strong statement, which I
will not attempt to defend - even though I agree because any
characterization of a given sequence tells you nothing about whether
the sequence is crytographically secure or not. You must characterize
the generator instead, not one of its output sequences.

If, however, you state that a TRNG is a device capable of generating
100% entropy - because the sequences it generates represent all
possible microstates for a given macrostate - then we are in full
agreement.

Here, of course, a macrostate represents the length of the sequence
(and the fact that we are using bits), and each microstate represents
one of the 2^N possible sequences of length N. The entropy density is
100% because all possible microstates are capable of being generated
equiprobably of a TRNG.

>Try a small example: we lnoy care about 2 bits: "00", "01", "10", and "11".  The
>four possible sequences are equally probable.  Can you compress them?

Those numbers are too small to make any kind of significant reduction
in complexity.

Bob Knauer


"Since the politician never believes what he says, he is surprised
when others believe him."
--Charles De Gaulle


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


** 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
******************************

Reply via email to