Cryptography-Digest Digest #298, Volume #11 Fri, 10 Mar 00 15:13:00 EST
Contents:
Re: Free-MAC mode (David Hopwood)
Q: Voice encryption (Mok-Kong Shen)
Re: ZIP format is gone in the past. ("Steve A. Wagner Jr.")
Re: Crypto Patents: Us, European and International. ([EMAIL PROTECTED])
Re: SHA-1 and Patents confusion with Hitachi (David Hopwood)
Re: Crypto Patents: Us, European and International. (John Savard)
Re: I have found that RC4 stinks.. (David Hopwood)
Re: Linking Time-Stamping Servers (Terje Mathisen)
If we spent as much time.. ("Steve A. Wagner Jr.")
Re: Best language for encryption?? (Paul Schlyter)
Re: Best language for encryption?? (Paul Schlyter)
Re: ZIP format is gone in the past. (Paul Schlyter)
Re: NIST, AES at RSA conference ([EMAIL PROTECTED])
Re: Cellular automata based public key cryptography ([EMAIL PROTECTED])
Re: Cellular automata based public key cryptography ([EMAIL PROTECTED])
Re: Best language for encryption?? (Darren New)
Re: encrypting to unknown public key? (David A. Wagner)
Re: Universal Language (SCOTT19U.ZIP_GUY)
Re: Q: Voice encryption (drobick)
----------------------------------------------------------------------------
Date: Fri, 10 Mar 2000 18:36:20 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Free-MAC mode
=====BEGIN PGP SIGNED MESSAGE=====
Adam Back 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.
>
> encryption is:
>
> y_i = E_k( x_i + y_{i-1} ) + x_{i-1}
>
> and decryption is:
>
> x_i = D( y_i + x_{i-1} ) + y_{i-1}
How are x_0 and y_0 defined? If you're not very careful, there appear to be
attacks which choose these values (e.g. if x_0 and y_0 are simply sent with
the ciphertext, I can see at least one known plaintext attack that involves
transposing the inputs to decryption for two blocks y_i and y_{i+1}, and then
XORing x_0 and y_0..y_{i-1} with a suitably chosen constant such that the
effect on the chaining variables after block i+1 cancels).
> In practice to make a MAC out of this you would append a fixed block to the
> message and verify that this fixed block was preserved on decryption. This
> block could be public, or perhaps could be the IV, or a separate key.
>
> We are working on a paper describing the Free-MAC mode, and output feedback
> as a way to get error propagation on the decryption operation of a block
> mode.
>
> The result is likely to be essentially as efficient as CBC encryption, and
> doesn't suffer the block swapping attacks that Propagating-CBC,
> Plaintext-CBC, iaPCBC and CBCC do.
I'm skeptical. Bearing in mind the attacks on all the other propagating modes,
I'd like to see a proven reduction from breaking the integrity check to
breaking the block cipher. Heuristic security isn't really good enough.
- --
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
iQEVAwUBOMlAdzkCAxeYt5gVAQEQhggAwSaUsExmLbRpWufM6GX+bhsjO1U9Fah7
QSDse34K1FnQOtvUNT+g8+yfhubbUbaCAxpF6l+VjsHwLV89VtpINLmYkqNPPPoP
OqADKWCJLrP+xCu020fHI3y5RRrO70z4S1H1pAzYxejFEpWmixen/uDx+sHSrMZj
k03Q714OT0XC6Jj4lCV3pptjlIu4um2p5qmL0lOGIWn4pLD6s9FUVtca+MywdpL+
BUGuf0l1HcS7hgtLQT2p2Yd/BE5a3weYDJ8KfXOhOTeEaKiuHJcC0hljyscFI4ZA
P1B2+K3jn4iAnnYMJ12LksHTir07iiBjNsD02VTUPyY4dTE/2qZucA==
=vvLU
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: Voice encryption
Date: Fri, 10 Mar 2000 20:03:50 +0100
For voice encryption, there are analog scramblers and digital
scramblers. Is there anything against using both with the
expectation of obtaining a higher security or does one use in
fact both in practice? What are the algorithms used in the
common types of digital voice scramblers? Thanks.
M. K. Shen
------------------------------
From: "Steve A. Wagner Jr." <[EMAIL PROTECTED]>
Subject: Re: ZIP format is gone in the past.
Date: Sat, 11 Mar 2000 10:00:06 -0800
I agree with your viral/cross platform concerns. SFX promotes ignorance. It's
ok for self-extracting install archives downloaded from CERTIFIED sites but
that is all.
--SAW
finecrypt wrote:
> It's more and more people prefer to use self-extracting executables instead
> of zip archives. FineCrypt is the most popular tool in the world for
> creating strong encrypted self-extractors. Try it now.
>
> http://www.finecrypt.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Crypto Patents: Us, European and International.
Date: 10 Mar 2000 18:45:26 GMT
In a previous article, Bill Unruh <[EMAIL PROTECTED]> writes:
> ] songwriter when some artist perform his work (why not an integer
algorithm
> ] when an application developer uses it?), it protects you to some extent
from
>
> An algorithm is an idea, not the expression of an idea. It is
> expressions that copyright protects and the law and the theory behind
> the law try very hard to distinguish between the two. Of course software
> houses would like copyrights broadened since they are a monopoly grant
> from the government.
It is hard to say if we materially disagree since we use the term "algorithm"
differently. I am not talking of algorithm as idealistic entities, but more
of examples in textbooks, portable fragments of source code etc. Thus, I am
in fact talking of expressions when I am talking of algorithms.
> These are again derived works which depend in an integral way on the
> original specific work. If the improved implimentation is an
> improvement derived from the text of the previous work, it is covered by
> copyright. If it is not, and is developed from the ideas then it is not.
True. But few - if any - developers implements e.g. IDEA from scratch just by
knowing the idea behind it. They look it up in crypto code libraries, copies
the code and make minor adjustments. THAT, I argue, is an violation of
copyright.
> The name is irrelevant and has nothing to do with copyright. I could
> call my algorithm to sort numbers IDEA. The name may or may not be
> protected by trademark and that is something different. This is why the
> public implimentation of RC4 is called ARC4, becasue RC4 is trademarked
> by RSADSI.
> Ie, if you called it IDEA you would probably be violating both copyright
> and trademark law.
[---]
> However I could write a poem
>
> Stop
>
> and the courts would rule that that could not be copyrighted since it is
> essentially the only way of expressing that idea. The longer a work is,
> the more improbably that a court would find that it was the unique
> expression of the embodied ideas.
I don't think so, but again we are talking of different things. Your poem
would not only consist of the word "Stop", but also of some sort of reference
to you and that particular instance of expression. E.g.
Stop ("Re: Crypto Patents: Us, European and International." by Bill Unruh)
I am arguing that the name of an algorithm, e.g. "IDEA", in the same way might
serve as a reference to a particular instance of expression.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
Date: Fri, 10 Mar 2000 18:42:24 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: SHA-1 and Patents confusion with Hitachi
=====BEGIN PGP SIGNED MESSAGE=====
Benjamin Gittins wrote:
> I am somewhat confused.
[...]
> Hitachi, Ltd., Intellectual Property Office
> http://grouper.ieee.org/groups/1363/letters/Hitachi.txt
Ignore Hitachi's patent claims on SHA-1; they are thoroughly bogus.
> similar issue with RIPEMED-160 by its authors.
> http://grouper.ieee.org/groups/1363/letters/Bosselaers.txt
Again, the Hitachi claim doesn't appear to me to have any relation
to RIPEMD-160.
- --
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
iQEVAwUBOMlB9TkCAxeYt5gVAQEPWQgAiEGz3Zki70CkOLMYIUPz7nRfy/s3foVQ
us3fz+KqrFOru8o0KE3g6xHqMlREwPVDKynbEI0D/pRHq+50GsvDOrgsI6fP6N65
DaUQVBYngIlgyrwTTDceRvq++O0TLwNVNzIjv+5bUz0/NNe8hINcUX3oS3ZXj1z2
sVgVPNoKST8l/7nRv9yhQJdI13Q/xcZxLEWUzm4Etdd2A3WLve5cdVeOyt7p0PTi
thZ2djZnSYFZXHfELkiYPQo7GalvM0cgljFo3iWGWc6UAm63Emfiy1A0z5xeYfyH
f+gmjaoxgeUf6Z5TFGdz0C3VXhtt5XcITHFwXl4LO96/PV3X8DmAcQ==
=KLO6
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Crypto Patents: Us, European and International.
Date: Fri, 10 Mar 2000 12:00:32 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>John Savard schrieb:
>> [EMAIL PROTECTED] (Bill Unruh) wrote, in part:
>> >No. Prior art invalidates all subsequent patent rights. Thus you, by
>> >making something public and thus prior art extinguish everyone else's
>> >right to patent that thing. Thus you can "give up the rights of others".
>> By making something public, that no one else has patented, you are not
>> taking away something that someone else owns. It's something
>> previously patented that one can't unpatent.
>How about publishing something which coincides with matters in the
>patent application of someone but has not yet been published by the
>office?
As Terry Ritter has noted, that can't cause them problems either.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Fri, 10 Mar 2000 06:45:58 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: I have found that RC4 stinks..
=====BEGIN PGP SIGNED MESSAGE=====
Nemo psj wrote:
> =
> Recently i have been working on a stream cypher i have created thi=
s
> cyphers strength comes from parts of the enigma machines setup and part=
of the
> programs ability to change the password after encrypting each letter. =
So i
> decided along with some suggestions from people to include in the passw=
ord
> change a more well tested and known algy. So i pick up an implementati=
on of
> RC4 and try to incorpaereate it. Unfortunatly i find it has a giant fl=
aw if
> your try to continuasly encrypt something like "&#$#!!~$=D76=EC" with s=
omehting
> like "))_+{}<?><@(^=BC" it will eventually return "".
I'm not certain how VB6 stores strings, but I suspect that they are null-=
terminated. Therefore, whenever the ciphertext includes a zero byte (whic=
h
will happen with 1/256 probability for each byte), the string is truncate=
d.
Eventually (when the first ciphertext byte is zero) it will be truncated
to "".
If this is the right explanation, it means that you can't use a string in=
VB
to represent a byte sequence, so whoever wrote the code you posted didn't=
know what they were doing.
It certainly isn't a problem with RC4 itself.
- -- =
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 0=
1
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMiZ8jkCAxeYt5gVAQEVmQf+NOtuzLuuooKTHEboec1gV934AuppzQ42
BiILGd3ATwrB+P0pfmzgTc5ewYntoOUa6wpp/JWkQ1bZTotLD2lsrnWCyLW+WvH+
sUIVhDLKl5pSrCPjP6PL9nm0yLzVFlE9tUeocAZfOmQ1vI3nvkPEiA51vfczZS4J
402zzA7cxozvzmEoXDVxc6L3HM6dNw3fB4LPxgHQvt3ksdqVe0HPe8TuhV2QLBWn
p+M4DNjTFKZjjVpCqdFZiO7hwVBgTdOHfXnAcMg6hBvnQmd7Iquj96V4PUaeS2M4
UnA3625C826Gxx71oUEX/swNiw3Bpw8UX+pcOE45l3xuaOuRg1JqJA=3D=3D
=3DOnGl
=====END PGP SIGNATURE=====
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: Linking Time-Stamping Servers
Date: Fri, 10 Mar 2000 20:06:56 +0100
Paul Koning wrote:
>
> Terje Mathisen wrote:
> > NTP is definitely the 'Right Way' to sync servers, ...
>
> Definitely *not*. It may be the cheapest, but the best way, which
> costs very little more, is to use GPS. That works world-wide, not just
> in the US. As I understand it, these days GPS is used as the way
> to synchronize primary time references in various countries. It's
> faster and much easier than the old way -- which was to put someone
> on a plane with a "portable" Caesium clock.
>
> GPS uses caesium clocks in the satellites, monitored by master clocks
> in the ground stations. The time data you get out of the receiver
> is good to less than a microsecond (since that corresponds to a 300 m
> positioning error, well outside the tolerance for GPS). You will NOT
> get that accuracy from NTP, nor from conventional radio time
> signals (MSF, WWV, etc.)
And how would you attach those clocks to your servers?
NTP is _the_ best piece of sw available to sync a system clock to an
external source, preferably using a Pulse Per Second (PPS) signal to
slave the kernel clock directly to the exterbak reference.
One of my reference servers, currently sitting in my office with the
antenna on an outside ledge, is a FreeBSD machine using a $400 Motorola
Oncore GPS receiver which is capable of 30 ns RMS precision.
That particular box uses the standard (bad) motherboard crystal, so when
I measured the error, I got something like 0.4 us of RMS jitter.
Poul-Henning Kemp, who wrote the Oncore driver, have also replaced the
motherboard crystal with an OCXO, he got significantly better than 0.1
us precision.
So, as I said, NTP is the 'Right Way', it is even an Internet standard
(RFC). :-)
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: "Steve A. Wagner Jr." <[EMAIL PROTECTED]>
Subject: If we spent as much time..
Date: Sat, 11 Mar 2000 10:16:46 -0800
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. Could the large population
of cipherpunks channel their efforts toward real crypto....
And if you lack the math background for this, as I do, there's nothing
wrong with designing software and hardware that use known and proven
security protocols.
Just a thought.... Please comment.
Putting on my flame-retardant vest now.
--SAW
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 10 Mar 2000 18:34:27 +0100
In article <[EMAIL PROTECTED]>, Darren New <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
>> Which there almost are: if a floating-point type is converted to/from
>> an integer type, some actual conversion is done, otherwise the bit
>> pattern is just copied. This originate from the K&R C paradigm
>> "Everything is an int" (including pointers, and excluding only
>> structs/unions and floating-point types).
>
> Pointers were never "just ints" in K&R C. They just had silent type
> conversions back and forth.
In actual K&R C code, pointers and int's were often assigned to one
another, and it usually worked. So if not in theory, then at least
in practice, pointers were just int's. ANSI C changed that a little.
>> syntax: the semantics behind it is usually just a copying of some
>> bit pattern (the only exception being when casting a floating-point
>> type to/from an integer type or another floating-point type).
>
> Nope. If you're using a machine where (for example) the null pointer isn't
> represented by a zero,
Could you name one such environment? Yep, I know it may happen in
principle, but I've never heard about a real system where it actually
does happen.
> or where pointers have different bit orders or bit patterns than integers,
> it certainly does convert pointers to integers on casts, and back again.
It MAY, but I don't see why it "certainly" should do this, except in the
case of assigning 0 to a pointer to get a NULL pointer (which is perfectly
legal in any flavor of C and C++).
> I'm not sure whether you're allowed to lose information if you cast a
> char* to a long, then to an int*, then back again, but there are
> architectures where a char* and an int* are two different size
> pointers.
On a word addressed machine you would lose such information: the int*
address would simply be a word address (since an int would have to be
stored at a word boundary), but the char* address would have to be a
word address, followed by some extra bits specifying the offset into
the word where the character was stored. If assigning a char* to
an int* (directly, or by a long as an intermediate storage) the
offset portion would get lost. Note that ANSI C explicitly specifies
that a void* must be able to point anywhere a char* is able to point.
> John Myre wrote:
>> silly. I don't think you can say C is "weakly typed", at least
>> not the current standard, because the compiler will actually
>> check stuff for you if you let it.
>
> I think that C is called "weakly typed" not only because of the casts that
> let you cast things to that which they aren't, such as casting "struct x" to
> "struct y".
You cannot cast a struct to another struct. But you can cast a pointer to
a struct to a pointer to another struct.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 10 Mar 2000 18:34:59 +0100
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
>> long l = 1000000L;
>> short s;
>> s = l;
>
> Of course, if your algorithm is wrong, you get wrong results.
Which means if the compiler allows you to silently convert
between these data types, you have a potential problem....
>> Which there almost are: if a floating-point type is converted to/from
>> an integer type, some actual conversion is done, otherwise the bit
>> pattern is just copied.
>
> No, in C conversions are of values, not representations. It may
> well happen that two types have similar representation, for
> example in C implementations on many word-addressable machines,
> all pointers to objects of size >= wordsize have the same
> representation, while pointers to objects < wordsize often have
> one or more different representations. Conversion among pointers
> having different representations is definitely not done by copying
> the bit pattern.
Maybe not the whole bit pattern is copied, but a subset. So
by copying a char* to an int*, the offset portion of the address
would be dropped, and only the word address would be retained.
>> This originate from the K&R C paradigm "Everything is an int"
>
> That was never quite true (consider "char"), and certainly is
> not the current paradigm.
>
>> unsinged int u = -1;
>> if ( u < 0 ) .....
>
> None of the C programmers I know would make that mistake,
How do you know that? Did you examine all of their code?
I have waded through a lot of code written by various people,
and I have seen stupid errors like this appear more often than
I expected -- even from skilled programmers.
> and indeed the compilers (or "lint" on the older systems)
> generally warn you about comparison of unsigned with
> negative integers (it's a constant condition, so it is
> most likely a bug).
Nowadays they do -- 10 years ago they didn't.... there is plenty
of old code still running...
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: ZIP format is gone in the past.
Date: 10 Mar 2000 18:35:40 +0100
In article <8aar8b$it7$[EMAIL PROTECTED]>,
finecrypt <[EMAIL PROTECTED]> wrote:
> It's more and more people prefer to use self-extracting executables instead
> of zip archives. FineCrypt is the most popular tool in the world for
> creating strong encrypted self-extractors. Try it now.
>
> http://www.finecrypt.com
The disadvantage of self-extracting archives are two:
1. They're single-platform only. Presumably your self-extracting
archive runs on Win32, which means it's useless for those who run
plain DOS, Win 3.x, or some variety of UNIX. Zip archives can be
unpacked on ANY platform, as long as you've got an unzipper for that
platform (I've seen unzippers for Win32, plain DOS, Win 3.x, UNIX,
and even good ol' CP/M-80).
2. Self-extracting archives are EXE files, and as any other EXE file
it may be infected by a computer virus.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST, AES at RSA conference
Date: Fri, 10 Mar 2000 19:16:15 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On 10 Mar 2000 08:38:19 GMT, in <[EMAIL PROTECTED]>, in
> sci.crypt [EMAIL PROTECTED] (D. J. Bernstein) wrote:
>
> >Terry Ritter <[EMAIL PROTECTED]> wrote:
> >> There is ample reason to believe that using multiple different
ciphers
> >> in sequence might hide weakness in a particular cipher:
> >
> >Ever heard of Shannon? How about Feistel? How about ``rounds''?
>
> I think that in the decade that has passed since we first had flame
> wars here on sci.crypt, I may have heard these terms mentioned once or
> twice.
>
Terry I asked you a question about the use of your method for public key
systems...but you refused to reply..dont be so arrogant..please reply if
you can...multiple PK ..sounds problematic. Can you imagine a user
having multiple secret keys, a DH, RSA , ECC key...???
To be honest with you, your method is more usefull if the divergence and
dis-similarity of the cipher design is greatest....
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cellular automata based public key cryptography
Date: Fri, 10 Mar 2000 19:16:15 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Theoretically, CA could be made to do quantum computation (QC)
>
> What "theory" is that?
>
This idea was first presented by Seth Lloyd in
Science Magazine volume 261, page 1569
(1993). Unfortuneately, I could not find a
description of this on the web but see, for
example, http://arXiv.org/abs/quant-ph/
0002034
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cellular automata based public key cryptography
Date: Fri, 10 Mar 2000 19:22:20 GMT
In article <8ab07r$d96$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dr. Yongge Wang) wrote:
> : Tim is correct. Theoretically, CA could be
> : made to do quantum computation (QC) which
> : could be more *efficient* than TM. There are
> : models of QC which are alternative to TM but
> : there is no proof I am aware of that any type
> : of QC is more powerful than TM in terms of
> : *what* can be computed.
>
> That depends on the "formal" definition of Quantum Computer.
> Real quantum physics is continuous (recall the
> phase \phi of a piece of glass if you use a piece os
> glass to shift the phase of a photon)
> This \phi can be any real number. The problem of a
> "formal" definition of a QC must use some approximations.
> This will make a QC discrete machine which is deemed
> to be at most as powerful as Turing machine.
> Indeed, the first task for each QC definition is to
> prove it can compute all functions that a TM can compute.
>
> Also note that a practical QC has to be discrete since you
> need to make combinations of the process and you have
> to observe it in the end.
>
A device could be built to do universal QC over
continuous variables. See, for example,
http://arXiv.org/abs/quant-ph/9810082
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Best language for encryption??
Date: Fri, 10 Mar 2000 19:32:33 GMT
Paul Schlyter wrote:
> > Pointers were never "just ints" in K&R C. They just had silent type
> > conversions back and forth.
>
> In actual K&R C code, pointers and int's were often assigned to one
> another, and it usually worked.
Yes. That's because of the type conversions. If you went
union x { char * cp; int ip} y ;
then assigned to cp and read from ip, it wasn't guaranteed to work.
Sure, it *might* work, but then indexing off the end of an array
*might* work.
> > Nope. If you're using a machine where (for example) the null pointer isn't
> > represented by a zero,
>
> Could you name one such environment? Yep, I know it may happen in
> principle, but I've never heard about a real system where it actually
> does happen.
I believe the AT&T 3B2 had this situation. NULL was 0x80000000 or some such.
Burroughs B-series machines had a very hard time running C, because machine
data was typed, and you couldn't convert a pointer to an int, for example.
(Altho I never programmed on a B-machine, so I might be a bit off here.)
> On a word addressed machine you would lose such information: the int*
> address would simply be a word address (since an int would have to be
> stored at a word boundary), but the char* address would have to be a
> word address, followed by some extra bits specifying the offset into
> the word where the character was stored.
Is that what the C standard says? Or is that just your recollection of
how the machines you used worked?
> You cannot cast a struct to another struct. But you can cast a pointer to
> a struct to a pointer to another struct.
Close enough. Or you can do
xxx.c: int f(struct x x_var) { ... }
yyy.c: extern int f(struct y); f(y_var);
No, you're not *supposed* to do that, but that's what makes C weakly typed.
The fact that there are things you can do that are undefined in the
semantics of the language, yet still compile. That's what weakly-typed
*means*. :)
--
Darren New / Senior MTS / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: encrypting to unknown public key?
Date: 10 Mar 2000 11:13:41 -0800
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> "David A. Wagner" wrote:
> > 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).
>
> Doesn't that fail to meet his requirement that you have to have
> the original public key to compute a blinded one? I think the
> above means blinding a blinded key produces another valid blinded
> key.
Oops. You are quite right. Scratch that idea...
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Universal Language
Date: Fri, 10 Mar 2000 20:43:53 GMT
In article <8ab3iv$22m$[EMAIL PROTECTED]>, "ink" <[EMAIL PROTECTED]> wrote:
>
>SCOTT19U.ZIP_GUY schrieb in Nachricht <8ab0h0$2ibo$[EMAIL PROTECTED]>...
>> Since American English is the language of the Technical age why not just
>>have everyone learn English.
>
>I wonder what 1.2 Billion Chinese and 1 Billion people from India say to
>that...
>
well China has lots of spies over here so it seems they could learn a
form of English easily. India the educated already speak English so whats the
problem
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: drobick <[EMAIL PROTECTED]>
Subject: Re: Q: Voice encryption
Date: Fri, 10 Mar 2000 21:06:49 +0100
Mok-Kong Shen wrote:
>
> For voice encryption, there are analog scramblers and digital
> scramblers. Is there anything against using both with the
> expectation of obtaining a higher security or does one use in
> fact both in practice? What are the algorithms used in the
> common types of digital voice scramblers? Thanks.
>
> M. K. Shen
http://www.ancort.ru/English/
------------------------------
** 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
******************************
