Cryptography-Digest Digest #353, Volume #11      Fri, 17 Mar 00 13:13:01 EST

Contents:
  Re: Quantum crypto flawed agains Mallory? (John Myre)
  Public timestamping servers (Logi Ragnarsson)
  Re: Quantum crypto flawed agains Mallory? (John Savard)
  Re: Quantum crypto flawed agains Mallory? (Tim Tyler)
  Re: Universal Language ([EMAIL PROTECTED])
  Re: NSA competitors ("Christoph Moser")
  Re: Public timestamping servers ("Christoph Moser")
  Re: Concerning  UK publishes "impossible" decryption law (Lincoln Yeoh)
  Re: [Fwd: Cyber Patrol Software Co. sues hackers ...] (Arturo)
  Re: java code for ellipse curve cryptography and ripme-160 ("Christoph Moser")
  Re: NIST, AES at RSA conference (SCOTT19U.ZIP_GUY)
  64-bit Permutations (Stephen Houchen)
  Re: ascii to binary (John Ferrell)
  Re: Quantum crypto flawed agains Mallory? ([EMAIL PROTECTED])
  Maybe public key is more secure ([EMAIL PROTECTED])
  Re: EOF in cipher??? (Jerry Coffin)
  Re: Improvement on Von Neumann compensator? (Tim Tyler)
  Re: EOF in cipher??? ("Trevor L. Jackson, III")
  Re: new Echelon article (Mok-Kong Shen)

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

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Quantum crypto flawed agains Mallory?
Date: Fri, 17 Mar 2000 07:19:33 -0700

[EMAIL PROTECTED] wrote:
<snip>
> Isn't Quantum Cryptography flawed against a malicious
> attacker, a traditional man-in-the-middle?
<snip>

Yes.

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

From: [EMAIL PROTECTED] (Logi Ragnarsson)
Subject: Public timestamping servers
Date: 17 Mar 2000 14:23:32 GMT

Hi!

I have written a simple time stamping server which returns the usual
signed timestamp of a short string you supply (should be a hash normally)
and with some features to allow third-party authentication of the logs.

Are there already servers like this on the 'net? Is this something that
is worth actually putting up?

Cheers,
Logi

-- 
Logi Ragnarsson ([EMAIL PROTECTED])  |  Some day we all shall be out of scope
PGP/GPG key ID: 1024R/42935585    |  Sex, Maths & Rock'n'Roll!

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Quantum crypto flawed agains Mallory?
Date: Fri, 17 Mar 2000 14:11:56 GMT

On Fri, 17 Mar 2000 10:56:15 GMT, [EMAIL PROTECTED] wrote, in
part:

>Could not she estabilish 2 separate
>communications negotiating keys with Alice and Bob and listening to
>everything?

An active attack certainly can work against quantum cryptography in
that fashion. One has to be the 'man in the middle' for both the
quantum channel and the conventional channel in which the two parties
attempting to construct a common one-time-pad note the times of their
successive observations and the directions of their measurements, but
except for this complication, such an attack is as possible as for
public-key systems.

John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Quantum crypto flawed agains Mallory?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Mar 2000 14:53:33 GMT

[EMAIL PROTECTED] wrote:

: I've just learned about Quantum Cryptography and how it is so
: unbreakable... Very interesting indeed!
: But I question arised in my head and I didn't get an answer for me
: so far... Isn't Quantum Cryptography flawed against a malicious
: attacker, a traditional man-in-the-middle?
: Suppose I have Alice, Bob and Mallory, this time not just
: eavesdropping, but also changing the communcation. She has a device in
: the middle of the cable/satellite/etc that can forge messages sent by
: Alice to Bob and forge the answers. Could not she estabilish 2 separate
: communications negotiating keys with Alice and Bob and listening to
: everything?

The quantum cryptography itself doesn't attempt to authenticate the
communicators.

That's partly why there's normally something like a telephone call as part
of the protocol - so the participants can authenticate one another.

*If* Mallory can /also/ intercept this, *and* fake the voices of each
participant well enough for fool the other one, the security's lost.

Otherwise, Mallory's attack will usually fail.  His manipulation of the
particles is *extremely* likely to be detected during the telephone call.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

The rat race is over.  The rats won.

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

From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Universal Language
Date: Fri, 17 Mar 2000 07:38:09 -0800

Borrowings from where?

stanislav shalunov wrote:

> [EMAIL PROTECTED] (Mike McCarty) writes:
>
> > The cases in Russian ar
> [...]
> >       vocative
>
> In Russian vocative is defunct.  There are three words that have it:
> "Otche", "Bozhe", and "Gospodi" (all three happen to refer to God and
> can be considered borrowings).  Average educated native speaker
> doesn't know anything about any "vocative."
>
> No dictionary or grammar recognizes it.




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

From: "Christoph Moser" <[EMAIL PROTECTED]>
Subject: Re: NSA competitors
Date: Fri, 17 Mar 2000 16:31:45 +0100

J�rgen Baumann wrote...
>Yes, forget about the BND, in Germany its called BSI (Bundesamt fuer
>Sicherheit in der Informationstechnik)
BND was right, the BSI is something different...

http://www.bundesnachrichtendienst.de
http://www.bsi.de

Christoph




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

From: "Christoph Moser" <[EMAIL PROTECTED]>
Subject: Re: Public timestamping servers
Date: Fri, 17 Mar 2000 16:53:11 +0100

Logi Ragnarsson wrote ...

> ...  time stamping server ...

>Are there already servers like this on the 'net? Is this something that
>is worth actually putting up?

in Germany e.g.

http://www.d-trust.de
http://www.timeproof.de/

in the US are e.g.
http://www.surety.com/
http://www.entrust.com/

offer such a service.

Christoph






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

From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To: 
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Re: Concerning  UK publishes "impossible" decryption law
Date: Fri, 17 Mar 2000 16:00:01 GMT
Reply-To: [EMAIL PROTECTED]

On Mon, 13 Mar 2000 00:14:59 +1100, "�R���" <[EMAIL PROTECTED]> wrote:

>I would probably go along with an electro-magnetic pulse set-up through a
>printer port, that if an incorrect login is done, the port turns on the
>magnet field over the top of the hard drives.

Are you sure you can generate a magnetic field strong enough to wipe data
from the top of a harddrive?

As far as I know, it's not so easy, especially nowadays.

But I am very certain turning it to slag makes it very difficult.

Cheerio,

Link.
****************************
Reply to:     @Spam to
lyeoh at      @[EMAIL PROTECTED]
pop.jaring.my @ 
*******************************

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

From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Subject: Re: [Fwd: Cyber Patrol Software Co. sues hackers ...]
Date: Fri, 17 Mar 2000 15:13:44 GMT

On Fri, 17 Mar 2000 11:49:26 GMT, jungle <[EMAIL PROTECTED]> wrote:


>Software Co. sues hackers
>BY TED BRIDIS AP Technology Writer 
>
>WASHINGTON (AP) -- A company that makes popular software to block
>children from pornographic Internet sites filed an unusual lawsuit late
>Wednesday against two computer experts who developed a method for kids
>to deduce their parents' password and access those Web sites.
>
        When will they just rely on good crypto/programming instead of
obscurity and lawyers...?


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

From: "Christoph Moser" <[EMAIL PROTECTED]>
Subject: Re: java code for ellipse curve cryptography and ripme-160
Date: Fri, 17 Mar 2000 17:02:34 +0100

kingtim wrote...
>please tell me where i can get java code for ellipse curve cryptography

http://www.cryptix.org/products/elliptix/index.html

...they also offer the source-code...

Christoph





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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NIST, AES at RSA conference
Date: Fri, 17 Mar 2000 16:54:12 GMT

In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]> 
wrote:
>John Savard wrote:
>> 
>
>> Also, this statement certainly _sounds_ like "since the AES isn't
>> provably strong, it might be terribly weak", which is why people turn
>> around and say that multi-ciphering, not being provably strong either,
>> has the same problem. Unless this is all an argument about who should
>> bear the burden of proof, you will need stronger evidence of a
>> probability that the AES may be weak to get people to take the extra
>> effort that multi-ciphering involves.
>
>I believe the word 'probability' above means 'subjective probability',
>which is a measure that can be different from one person to another.
>Providing evidences can affect that measure. But how can one SHOW
>that AES may be weak except by demonstrating a concrete method
>that, eventually on the basis of some technological advancements 
>that are apparently within the reach of the opponent in the 
>foreseeable future, to attack it with certain quantifiable measure 
>of efficiency? The best of the academics are doing exactly that 
>very job, I suppose. So, unless one is actually (or believes oneself
>to be) smarter than these academics, one is left with a decision 
>that is in my humble view not very much different from a decision 
>that one makes in many sorts of common gambling situations.

  Actually this is quite different than most gambling situations.
As surely as the government will use the census information to
cause its citazens troulbe as it did the Japanese Americans
dumb enough to tell the US they considered them selves of
Japanese extraction.  The AES that the NSA finally allows to be
aproved will be easy for the NSA to break and read ones emails
or other data which foolish people will try to encrypt. They will
rightly assume that 99.9% of the people will not double encrypt 
and that the AES method will be widely used in its blessed state.
   The best of academics is in bed with uncle Sam so it is BULLSHIT
to assume real work is being done in the open to break any of these
ciphers. THe one will get stuck with is the one the NSA wants us to
use. To think otherwise ignores the whole history of the US govenment
and the very increasing way it lies to its people.


 


David A. Scott
--

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
                    
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm

Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm

Scott famous Compression Page WIMPS allowed
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: Stephen Houchen <[EMAIL PROTECTED]>
Subject: 64-bit Permutations
Date: Fri, 17 Mar 2000 10:37:28 -0600

Imagine a cipher where you took plaintext in 64-bit blocks.
The bits in each block are simply permuted in the same
fashion for each block. The key, then would be the bit-
mapping.

My gut feeling is that this is so simple that it's probably not
very hard to break.

So cryptanalysts, how would you break it?

S
[EMAIL PROTECTED]


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

From: John Ferrell <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers
Subject: Re: ascii to binary
Date: Fri, 17 Mar 2000 16:46:23 GMT

Binary read was available on the IBM 2821/2540 combination as a feature. As I remember 
it was mainly a conversion tool. Punching
binary on the 2540 was a no-no. You might get a few cards through, but a jam or a 
broken punch unit was not far away.

There was a project in the late sixty's that required a conversion of data (duck 
banding records) from some card that would feed on
the 2540 but it had round holes and I think 50 columns. Anyway the programmer & I put 
our heads together and I wrote a simple
program to transfer whatever the card image read to a reel of tape and he translated 
the tape into conventional data. All of a
couple of hours!

wtshaw wrote:

> In article <[EMAIL PROTECTED]>,
> "Alan J. Flavell" <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 7 Mar 2000, Anne & Lynn Wheeler wrote:
> >
> > > http://www.cs.uiowa.edu/~jones/cards/codes.html
> >
> > I dimly remember being at one installation where they used
> > binary punched cards.  But the card readers themselves were unable
> > to handle this (they could only read BCD characters).
> >
> > The binary cards were read in the card punch, by "punching" them full
> > of blanks and then passing them through the punch's check-read station
> > and picking up the "punching errors".
> >
> > I've no idea how common this practice was.
> >
> > all the best
>
> BCD was true with the IBM 1620 output, which could be cards to read on the
> separate BCD card reader.  Later, we had a Xerox Sigma 7, which could use
> either format.  The keypunches were different, including some labeling of
> the keys themselves.  The biggest thing was breaking the 60000 core
> barrier that the our 1620, mod II, had.
>
> BCD did allow some strange control characters that we no longer see in
> sets. Of particular interest to me for crypto work was A format which
> Forgo allowed; Forgo was a compiled variety of Fortran in a stack of cards
> which had to be reloaded to the 1620 if there was a crash.
> --
> Imagine an internet on an up and up basis, where there are no subversive techniques 
>to rob a person of their privacy or computer
> functionality, no hidden schemes used to defraud anyone. :>)

--
John Ferrell in Julian NC, de W8CCW
  Dixie Competition Products
   6241 Phillippi Rd
    Julian NC 27283
Phone: (336)685-9606  Fax: (336)685-9771
NSRCA 479         AMA 4190
"My Competition is Not My Enemy"



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

From: [EMAIL PROTECTED]
Subject: Re: Quantum crypto flawed agains Mallory?
Date: Fri, 17 Mar 2000 16:47:04 GMT


> The quantum cryptography itself doesn't attempt to authenticate the
> communicators.
>
> That's partly why there's normally something like a telephone call as
part
> of the protocol - so the participants can authenticate one another.
>
> *If* Mallory can /also/ intercept this, *and* fake the voices of each
> participant well enough for fool the other one, the security's lost.
> Otherwise, Mallory's attack will usually fail. His manipulation of the
> particles is *extremely* likely to be detected during the telephone
call.

   Maybe it would be practical to exchange a few bits via quantum by
sending the polaroid types via telephone (and thus authenticate the
participants in the communication), but for large files it would be
absoultely impractical to exchange a one-time pad this way!
   This authentication should be done in a standard computer line, so
it would not be sufficient to exchange the data securely. I know
quantum crypto have interesting proprieties, but is it practical and
secure even assuming the proper technology is developed?

Daniel.



Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED]
Subject: Maybe public key is more secure
Date: Fri, 17 Mar 2000 17:07:29 GMT


> An active attack certainly can work against quantum cryptography in
> that fashion. One has to be the 'man in the middle' for both the
> quantum channel and the conventional channel in which the two parties
> attempting to construct a common one-time-pad note the times of their

   That would not be a problem. If the security is based on the
existence of multiple channels, we could make any cryptography
algorithm more secure by the use of more channels to transmit the
message.
   We should also consider that the man-in-the-middle attack is also
easier in the kind of communication that quantum crypto requires. The
system is very dependent of precise light beams, and it facilitates the
use of a device between the parties communicating. It is much more
difficult to intercept and forge radio beams (that traves on the air
for all directions) that photon beams, provided the technology for
receiving and emmiting the beams are already in the public domain.
   We have also the problem of securing the line. If we need to
absolutely secure the line for a quantum communication, what's the
reason of cryptography? If the line is tamper-proof, no one could
eavesdrop the conversation, so we could send the text in plain format!!
   I will not even mention the fact that quantum cryptography does not
solve the problem of encrypted message archiving... In this case, we
only could use the conventional algorithms.
   If a quantum computer is some day descovered, people would be in a
great trouble with conventional algorithms!! Well, at least
cryptoanalysis would be again fun, since the focus would be more in
cryptoanalysis techniques than in making algorithms and computers
faster for force brute attacks!

> successive observations and the directions of their measurements, but
> except for this complication, such an attack is as possible as for
> public-key systems.

   We have the Interlock Protocol that solves a great deal of the
problem in public key systems. In that case, exchanging keys in public
key algorithms are much more man-in-the-middle proof that the quantum
communication.

Daniel.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 17 Mar 2000 10:27:29 -0700

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin wrote:
> > Almost undoubtedly.  Unfortunately, "strictly conforming programs"
> > and "useful programs" are pretty much disjoint subsets, so this
> > doesn't really mean much.
> 
> Nearly all my C code is (usable as part of) a strictly conforming
> program. 

Writing routines that are strictly conforming is easy to believe.  
Writing a useful program that's strictly conforming is essentially 
impossible.

A strictly conforming program can't produce output that depends on 
anything that's implementation defined, unspecified or undefined.  In 
C, anytime you write something to a file, you get results that are 
implementation defined, so a strictly conforming program can't write 
to a file.  If you can think of a way for a program to produce output 
without writing to a file, and remain even _close_ to strictly 
conforming, I (for one) would really like to hear about it.  If you 
can come up with a way for a program to be of much use without 
producing any output, that would be quite a revelation as well.

> That is good programming practice, as it enhances
> portability.  System-specific stuff can usually be isolated to a
> few interface files.

That's the theory -- in my experience the reality is the opposite: 
you can isolate the system-specific stuff by itself all right, but it 
ends up as about 90% of the program in most cases.  Of course, this 
depends a bit on what sorts of programs you write: if you can get 
away with practically no UI, it's easy to make most of a program 
portable.  If you need a reasonably modern UI, you usually end up 
with a LOT of non-portable code to implement it.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Improvement on Von Neumann compensator?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Mar 2000 17:22:05 GMT

Scott Nelson <[EMAIL PROTECTED]> wrote:
: On Thu, 16 Mar 2000 15:17:44 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Guy Macon <[EMAIL PROTECTED]> wrote:

:>: I know that if I XOR a true random bitstream with any other bitstream
:>: (except those derived from the true random bitstream), the result
:>: will be a true random bitstream.  Can this property be proven for
:>: any cryptologically strong hash functions such as SHA1?
:>
:>It can be practically proven false - the hash of a fixed-length finite
:>random bitstream is never itself random - though it can become /very/
:>nearly so.

: For CRC, that's provably false. [...]

Well, CRC is not "a cryptographically strong hash function such as SHA1".

You /could/ feed it through a block cypher - and that would randomise it
effectively without losing any entropy at all - but /that/ is not a
"cryptographically strong hash function" either.

: It's possible for a secure hashing function to have
: the same property.  For example;

: Use Twofish to crypt the first 16 bytes with a fixed key.
: XOR the output with the key and the next 16 bytes, 
: and crypt again.  Repeat until all bytes are used.

To clarify - you're describing a hash function - i.e. previous blocks
are discarded, and only the final block is output?

And you're claiming this construct is "balanced" - i.e. for all possible
inputs (with a size of some specified number of blocks), it produces
all possible outputs with exactly equal frequency?

Can you demonstrate that - or explain why it might have this property?

*Any* cryptologically strong hash function need not exhibit the property
in question.

However *some* types of strong hash function /may/ offer it - though I
don't personally know of any that do.

: I don't think SHA1 has this property, but I do believe
: it's flatter than a "random" hash would be.  (a hash
: that maps inputs to outputs at random).

After briefly looking at it's innards, I can't see why it would be.

: But even with a "random" hash we'd expect all 2^160 
: possible input strings to hash to 2^160/e output strings 
: - a loss of less than 1.5 bits, or .991 "real" bits per
: bit.

Yes.  I don't think the problem is a terribly practical one.

Hashing a totally random stream does not generally produce another
totally random stream, though.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

6.6.6 - IP address of the Beast.

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

Date: Fri, 17 Mar 2000 12:58:34 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???



Jerry Coffin wrote:

> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > Jerry Coffin wrote:
> > > Almost undoubtedly.  Unfortunately, "strictly conforming programs"
> > > and "useful programs" are pretty much disjoint subsets, so this
> > > doesn't really mean much.
> >
> > Nearly all my C code is (usable as part of) a strictly conforming
> > program.
>
> Writing routines that are strictly conforming is easy to believe.
> Writing a useful program that's strictly conforming is essentially
> impossible.
>
> A strictly conforming program can't produce output that depends on
> anything that's implementation defined, unspecified or undefined.  In
> C, anytime you write something to a file, you get results that are
> implementation defined, so a strictly conforming program can't write
> to a file.  If you can think of a way for a program to produce output
> without writing to a file, and remain even _close_ to strictly
> conforming, I (for one) would really like to hear about it.  If you
> can come up with a way for a program to be of much use without
> producing any output, that would be quite a revelation as well.

This sounds like an accurate assessment of so-called "side effect free languages", 
e.g., Lisp, that were once touted as great improvements over procedural languages.  
Needless to say all IO counts as a side effect, so a truly side effect free program 
cannot have a utility greater than zero.

>
>
> > That is good programming practice, as it enhances
> > portability.  System-specific stuff can usually be isolated to a
> > few interface files.
>
> That's the theory -- in my experience the reality is the opposite:
> you can isolate the system-specific stuff by itself all right, but it
> ends up as about 90% of the program in most cases.  Of course, this
> depends a bit on what sorts of programs you write: if you can get
> away with practically no UI, it's easy to make most of a program
> portable.  If you need a reasonably modern UI, you usually end up
> with a LOT of non-portable code to implement it.

If you write (or try to) high quality code you end up spending most of your code 
handling potential errors.  Since you typically design out error artifacts with 
internal causes almost all of the errors have external causes.  Thus the vast bulk of 
your code is concerned with issues that cannot ever be standardized.  And good error 
handling cannot be isolated.  In order to recover/continue you often need to handle 
errors in situ rather than just delegating them to an error _reporting_ mechanism.


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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,alt.politics.org.nsa,talk.politics.crypto
Subject: Re: new Echelon article
Date: Fri, 17 Mar 2000 19:09:22 +0100

The following is taken from New Scientist, 11 Mar 00, p.15 :

     Intelligence agencies won't have any trouble working out
     how to snoop unnoticed on satellite phone calls. The 
     information has just been published in patents filed by
     Motorola in the US and Europe.

Also on the same page:

     Cellphone users can now be pinpointed with accuracy of a
     few metres.

Presumably one has no essential difficulty to conceive how capable
and omnipresent one's big brothers are.

M. K. Shehn

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


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