Cryptography-Digest Digest #272, Volume #11 Tue, 7 Mar 00 13:13:01 EST
Contents:
very long passwords. (Was: Re: ...but what about my cipher?) (Tony L. Svanstrom)
Re: Cellular automata based public key cryptography (Tim Tyler)
PC risks analysis? ("Mykhailo Lyubich")
Re: Universal Language: was The Voynich manuscript ("Tony T. Warnock")
libdes / Linux ELF shared library (Matthias Bruestle)
Re: very tiny algorithm - any better than XOR? (Carl Byington)
Re: Crypto Speeds... (Runu Knips)
Re: very long passwords. (Was: Re: ...but what about my cipher?) (Runu Knips)
Re: Decompiling/Tamper Resistent (Paul Koning)
Re: ascii to binary (Paul Koning)
Re: Best language for encryption?? (Paul Koning)
Re: Excel password remover ("Tobiass Mai")
Re: ascii to binary (wtshaw)
Re: sci.crypt Cipher Contest (Bob Silverman)
Help me to win a challenge! (Oriol =?iso-8859-1?Q?Quinquill=E0?= Capdevila)
Re: The Voynich manuscript (Mok-Kong Shen)
Re: Universal Language: was The Voynich manuscript (Mok-Kong Shen)
Re: Cellular automata based public key cryptography (Mok-Kong Shen)
Re: Decompiling/Tamper Resistent (Jerry Coffin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Subject: very long passwords. (Was: Re: ...but what about my cipher?)
Date: Tue, 7 Mar 2000 14:14:41 +0100
Runu Knips <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] schrieb:
> > Why not? All you have to do is to place the Linux partition on your HD (or
> > some other partition you never use) in the clipboard and paste it. ;-)
>
> Unused Linux partitions ?!?!?
>
> Sounds like a beggar which never touches the millions on
> his bank account...
But it does raise one interesting question; instead of having to
remember a password you could remember a pattern and apply that to a
very large text (or other known to remain the same form of data). The
resulting password wouldn't be as strong as it should be if you only use
a small part of it but its length would clearly make up for that.
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---���---���-----------------------------------------------���---���---
\O/ \O/ �1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Reply-To: [EMAIL PROTECTED]
Date: Tue, 7 Mar 2000 13:55:59 GMT
Dr. Yongge Wang <[EMAIL PROTECTED]> wrote:
: I have just checked that page. I am not familiar with CA. But I am
: familiar with FSM (from Hopcroft etc. book). It seems that
: CA is a completely different notion than the Finite Automaton.
: CA equiv Turing machine, so are different from Finitte Automaton.
Cellular automata can be either infinite in extent, or they can be finite
- with periodic boundary conditions (or simply edges).
The automata under discussion at the start of the thread were
actually finite cellular automata. As such they were a subset of
the set of finite state machines.
The discussion about the relative computational power of these entities
seems rather irrelevant as far as cryptography goes.
The idea of a cypher machine that the user bolts unboundedly more and more
memory onto as it's required seems rather silly. Cyphermachines are
typically finite boxes.
Finite cellular automata can stimulate finite state machines - and visa
versa. Both can compute recursive functions - at least as far as their
memory allows. Both classes contain systems that can compute the same set
of functions that a stand-alone desktop computer can.
Consequently, there's no obvious reason to choose one over the other, on
the grounds of the complexity of the functions they can express.
If my bringing up Turing machines has confused this issue, I'm sorry.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Jesus saves - Vishnu invests.
------------------------------
From: "Mykhailo Lyubich" <[EMAIL PROTECTED]>
Subject: PC risks analysis?
Date: Mon, 6 Mar 2000 16:32:12 +0100
Hi there
does somebody know an official source (report, standard)
with "how vulnerable be a PC environment"?
I look for risk analysis survey or research report
for software encryption and password based data storing
on user's workstation.
I appreciate your help.
Mykhailo Lyubich
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Universal Language: was The Voynich manuscript
Date: Mon, 06 Mar 2000 21:11:07 -0700
Reply-To: [EMAIL PROTECTED]
The have been several reasons for the failure of "universal languages"
to become wildly popular. (There is no Esparanto Channel showing movies,
music videos, and ugly rotating jewelry.) Those like Esparanto reflect
the tastes and more importantly the vocabulary of the creator. Esparanto
is very Euro-centric. This is not bad per se, but it makes Esparanto no
easier than Spanish, English, German, Deutch, French, etc. Learning one
of the others allows one access to more people and litterature.
Languages like Lojban and it's relatives are equally difficult to learn
for people of all backgrounds.
The biggest problem is that languages are dynamic. They change with time
to accomodate new needs and tastes. In addition, the "generally accepted
standard" language has had lots of contributors. (In English, not even
an academy.) Features and vocabulary are added as needed. Good (or at
least adequate) ideas remain while others fall out of use.
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: libdes / Linux ELF shared library
Date: Tue, 7 Mar 2000 10:35:53 GMT
Mahlzeit
I want to compile libdes as position independent code because I
want to compile it into a PAM module which is a shared library.
I have not yet decided if I compile it into a shared library or
not (security?).
Can I use the assembler files for this or not? I ask this, because
position independent code reserves one register. Has someone maybe
build already a source rpm for this? I haven't found one.
Thanks
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
When a program is useful it must be changed,
when it is useless it must be documented.
--
insanity inside
------------------------------
From: [EMAIL PROTECTED] (Carl Byington)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 7 Mar 2000 16:20:41 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <8a28n0$v2$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>In article <89sm5g$826$[EMAIL PROTECTED]>,
>Carl Byington <[EMAIL PROTECTED]> wrote:
>>I will ask about this. I would be more than happy to have someone that
>>knows what they are doing help with this. When this project started,
>>everyone assumed we had enough code space to do TEA. The failure of that
>>assumption has pushed me into trying to design a moderately secure but
>>very tiny algorithm, which is clearly outside the boundaries of my area
>>of competence.
>
>It seems to me that rather than obsessing about fitting the cipher into
>50 bytes, you can probably spend the time bumming a few dozen more
>bytes out of the rest of the code, especially if it's written in C
>and you can tweak the compiler output.
Folks are working on that approach, but there is also some extra
required functionality that is not implemented yet. Our current
assumption is that the extra functions will chew up any code savings.
>The other thing (I said this before but had made a typo in it) is that
>unless you have seriously tamper resistant hardware (which you don't),
>cryptanalysis isn't going to be too big an issue. If I were attacking
>your system and didn't see within about 5 minutes how to break the
>cipher, I'd move on to a hardware attack. If there are any off-chip
>wires where unencrypted data goes in your circuit, you have no
>security at all no matter what encryption you use. Even if all the
>secrets never leave the chip, if your content is really valuable then
>you're still fairly open to attackers with serious lab equipment.
>Cable TV pirates do that kind of stuff all the time. So I wouldn't
>spend that much time obsessing about the cryptography in a system like
>this. I'm assuming you're making some kind of high-volume consumer
>gadget or else you wouldn't be talking about such cheap parts. So
>it's almost certain that attackers will be able to get some to take apart.
Quite correct. However, the content we are protecting is very cheap,
on the order of 1 or 2 dollars. The hardware is not particularly tamper
resistent, so anyone with access to a lab could clearly open the device
and attach probes. We are attempting to prevent the attacker from
decoding the content and then producing some software that will allow
loading that content into multiple other devices without also opening
those other devices. Each device contains a serial number (key) that
it uses to decrypt stuff, and also a 3des encrypted version of that
device key. It provides the encrypted version of its key on request to
some client software running on Win9x which simply passes that encrypted
key to a web server. There is a global key which is used to encrypt
all the device keys, and clearly if that is broken all is lost. That
global key is used to decrypt the device key, and then the device key
is used to encrypt content destined for that single device. Even if the
attacker does attach probes and therefore obtain the clear text of the
content (don't bother with the encryption, just read it directly from
the 1MB eeprom memory), they cannot load that content into other devices
without knowing those device keys.
If they obtain the global key, all is lost. The global key is known to
the web server, so security there is critical. The global key is also
known to the internal machines that produce the key lists.
- --
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E 06 1E 95 F8 74 A8 2F A0
=====BEGIN PGP SIGNATURE=====
Version: 4.5
iQCVAgUBOMUsRtZjPoeWO7BhAQFwMgP/chpTi07Bkyy18ZiElTnMZuBPQUth1c/N
r42KOiXf/l2IANh1rHJvQAVq7vU9Z32CQea9hItV3KhoHgb4WqDpQ8Cae7UKTzlg
vY/CsVn9Zs0ZsoV9b6DQcp0RKA7HDs9cCV5PO5Kj2cKPa+Ek+kpSWqAUojZIM3xX
fcS5LBEBYrI=
=Vx3w
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 07 Mar 2000 17:28:21 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Crypto Speeds...
Eric Young wrote:
> For most crypto using non-standard constructs, hand coding is a big win.
> Most CPUs give a 2x speedup for RSA/DSA/DH etc [...]
> For General algorithms like RC4/SHA-1/MD5, for most modern OOO CPUs,
> it is normal for good C code, loop unrolled, to be about %70-90 of
> what the ASM programmer can get. [...]
But in practice I would use the GNU MP libary for code like this.
Then you have assembly for the important computations - at least
for all important and most not-so-important architectures. Plus,
GMP ist L-GPL - so you can use it anwhere. So your RSA/ElGamal
etc. will be - okay, still not really EASY - but far easier 8-)
This way you can use assembly without even knowing a single
opcode of the machine you're working on.
------------------------------
Date: Tue, 07 Mar 2000 17:33:51 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: very long passwords. (Was: Re: ...but what about my cipher?)
"Tony L. Svanstrom" schrieb:
>
> Runu Knips <[EMAIL PROTECTED]> wrote:
>
> > [EMAIL PROTECTED] schrieb:
> > > Why not? All you have to do is to place the Linux partition on your HD (or
> > > some other partition you never use) in the clipboard and paste it. ;-)
> >
> > Unused Linux partitions ?!?!?
> >
> > Sounds like a beggar which never touches the millions on
> > his bank account...
>
> But it does raise one interesting question; instead of having to
> remember a password you could remember a pattern and apply that to a
> very large text (or other known to remain the same form of data). The
> resulting password wouldn't be as strong as it should be if you only use
> a small part of it but its length would clearly make up for that.
Hmm actually I was just making a joke...
This concept sounds like a salt, doesn't it ? If the attacker
knows your salt, he can still check all weak passwords and
attack your ciphertext, even if the resulting key was extremely
large. The only thing which changes is, both the encrypting and
the decrypting process became very slow and so the attacking
will become slower, too.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Decompiling/Tamper Resistent
Date: Tue, 07 Mar 2000 11:44:13 -0500
Jerry Coffin wrote:
> ... We're quickly reaching the
> point that the sizes involved are close enough to the wavelengths of
> light that it's soon going to be quite difficult to look at them with
> optical microscopes no matter how good people are.
Actually, we hit that point some time ago. 0.25 micrometer and smaller
are very common feature sizes. Those you can't resolve with a visible
light optical microscope, since it's well below the wavelength even of
blue light. This is why the masking is done using far-ultraviolet
light sources.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Tue, 07 Mar 2000 11:58:03 -0500
Vernon Schryver wrote:
>
> In article <[EMAIL PROTECTED]>,
> wtshaw <[EMAIL PROTECTED]> wrote:
>
> >> Didn't cards have 12 rows and 80 columns for decades before the 96-column
> >> cards arrived in the 1970's? Weren't the twelve holes on the classic
> >> punched cards labeled 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, + and - (at least
> >> by how you would punch individual holes to generate non-standard
> >> combinations).
>From top to bottom: + - 0 1 2 3 4 5 6 7 8 9, that makes 12 rows.
Those date back to Herman Hollerith and the 1890 Census. The 96-column
cards were an oddball for the IBM System 3, never seen before or since.
> My recollection about the names of the 11 and 12 punches may be wrong.
> The yellow card says '+' was a 12-0-7-8 punch, so I can't explain my
> memories of using '-' and '+' for over-punches.
You were right. The names comes from the older "026" code, a.k.a.
"BCD" (I think), which had a single punch in the top and next row for
plus and minus respectively. The yellow card you cite is giving
you "029" codes, which are the same for uppercase letters and
digits, but different for some punctuation.
> I'm sure that's very nice, but what do you mean by *the* tape device?
> Far more than one model from one vendor used paper tape. Paper tape was
> a very common low speed medium from at least the 1960's when I started in
> the business until the late 1970's. The closest to a universal paper
> format were the 5 and 8 level standards that Teletype (i.e. Ma Bell)
> defined for TTY's. Minicomputer vendors of the 1970's tended to define
> their own formats. When dealing with binary, the people defining paper
> tape formats were not happy to make the tape 14% longer by spending 1 bit
> in every frame on parity.
There was also a 6 bit paper tape standard used in the typesetting
industry. And, if you insist, a 2 bit paper tape, for machine-sending
Morse code. ("Wheatstone" code.)
BTW, Teletype is not Ma Bell, it's a separate company.
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
>> See Recommended USA Standard Code for Information Interchange (USASCII)
>> X.34-1967 (and predecessors) which define encoding some characters and control
>> codes into 7 (yes, only seven). I know of no standard encoding into
>eight bits,
>> other than adding parity.
As for that comment, it's about 25 years out of date. In the mid 70s,
or thereabouts, the ISO 8859 series of codes were defined, which
use 8 data bits. The lower half corresponds to USASCII; the upper
half adds more printable characters as well as more control characters.
There are about a dozen members of that series. As Doug said, Latin-1
(ISO 8859-1) is the best known in Western countries because it was
designed to support the languages of Western Europe. If you're
elsewhere
in the world you're likely to be using an 8859-somethingelse if you
have a Latin alphabet, or something entirely different if you have
a different sort of alphabet (like Cyrillic or Hebrew).
ISO 10589 and Unicode, which are closely related, use wider characters
to allow coding of essentially any character you might need without
having to switch back and forth among sets (which was never standardized
and would have been a processing nightmare even if standardized, which
is one reason it wasn't).
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Tue, 07 Mar 2000 12:00:53 -0500
Gautier wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > It was considered years ago that languages like Pascal and C were weakly
> > typed. Ada came along with a big promise..but has not found widespread
> > acceptance...
>
> A small precision: Pascal and Ada (83 or 95) have about the same level of
> typing (far from C). There are some differences. Ada doesn't accept implicit
> type conversions (spares many unintentional 8 <-> 16 <-> 32 bits conversions)
> but is more flexible than Pascal (e.g. unconstrained array types) while
> a little bit more strong-typed.
Algol 60 is the original strongly typed language; all the others
(Pascal, Modula, Algol 68, Ada) derive from that. C is indeed
very weakly typed. C++ has a fair amount more type checking
but still nothing like the strongly typed descendants of
Algol 60.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: "Tobiass Mai" <[EMAIL PROTECTED]>
Subject: Re: Excel password remover
Date: Tue, 7 Mar 2000 17:58:19 +0100
Thanks for your answer!
Regards
Tobiass
<[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
8a13ji$i76$[EMAIL PROTECTED]
> In a previous article, "Tobiass Mai" <[EMAIL PROTECTED]> writes:
> >Hello!
> >But i think in one way the xls-files are the property of Microsoft!?
Or?
> >
> >Regards
> >Tobiass
>
> You are, in a sense, right. I would say that Microsoft does own the
xls-format
> as such. But it would be no more wrong to tamper with an individual
xls-file,
> than it would be to rip out the editor notes from a single copy of an
> anthology. The owner of the file/copy might get upset and sue you, but
hardly
> Microsoft/the editor.
>
> Your problem is more likely to be of a differnet kind. MAYBE MicroSoft
would
> consider the coded ability to interpret xls-files as their property.
Your
> application MIGHT then be considered as a copyright violation based on
its
> ability to open, interpret and save xls-files, rather than because of
what
> your program in each case actually does to these xls-files.
>
> I however do not think that the xls-format is sufficiently original to
fall
> under any kind of copyright protection.
>
> ----- Posted via NewsOne.Net: Free Usenet News via the
eb -----
> ----- 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]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: ascii to binary
Date: Tue, 07 Mar 2000 10:26:46 -0600
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. :>)
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Tue, 07 Mar 2000 17:36:58 GMT
In article <mUBw4.3421$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
> I see a lot of ideas for encryption algorithms posted to sci.crypt
all the
> time, and I know several regular posters have thier own ciphers they
have
> developed. Since most of us are amateur cryptographers
I intend no offense to you or anyone else. BUT:
Ever heard the phrase "a little knowledge is dangerous"?
In my opinion, there is no such thing as an "amateur cryptographer",
any more than there is such a thing as an "amateur brain surgeon".
"amateur" is a synonym for "I have not studied this subject sufficiently
to be competent".
, and study
> cryptography for fun. I thought it might be fun to have a contest
such as
> AES.
Oy Vay. I very seriously doubt whether there are more than 3 regular
contributors to this newsgroup who are actually competent to design
one.
And at the end we could select the best cipher based on the criteria
> we decide on.
And this group as a whole certainly is NOT competent to do the judging.
This whole idea is a waste of time IN MY OPINION.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Oriol =?iso-8859-1?Q?Quinquill=E0?= Capdevila <[EMAIL PROTECTED]>
Subject: Help me to win a challenge!
Date: Tue, 07 Mar 2000 18:55:46 +0100
Hello!
I'm a studying in Catalan Polytechnic University, in Barcelona.
The students of IEA (something like Introduction to Algorithmics),
have been challenged to solve a [very easy, I know] cryptographic
problem.
Given the English alphabet, they're going to make a permutation
(for example: A->C (C->A), B->Z (Z->B), D->K (K->D), and so on),
and using it they will encrypt a text. Given the cipher, we have to
recover
the original text.
* * * The winer is the one who develops the algorithm which consumes
less CPU ***
I belive the best way should be implementing the A* (or maybe
Branch&Bound)
algorithm, using the freq�ency of use of letters in English as
heuristic.
Does anyone know a better idea? Any comment or suggestion?
Where can I find usefull information? I may also need powerfull data
structures (maybe a dictionary)... where can I find it?
Thanks!!
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: The Voynich manuscript
Date: Tue, 07 Mar 2000 19:04:01 +0100
[EMAIL PROTECTED] wrote:
>
> I haven't identified any language, just structures.
If you have identified a certain grammatical structure, then
you have identified a language, namely a language with that
grammar, in my view. Could you please sketch that grammar?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Universal Language: was The Voynich manuscript
Date: Tue, 07 Mar 2000 19:03:53 +0100
Tony T. Warnock wrote:
>
> music videos, and ugly rotating jewelry.) Those like Esparanto reflect
> the tastes and more importantly the vocabulary of the creator. Esparanto
> is very Euro-centric. This is not bad per se, but it makes Esparanto no
> easier than Spanish, English, German, Deutch, French, etc. Learning one [snip]
I agree with you. However, I think that it is possible to design,
first of all, a grammar that is simple, i.e. rational and without
exception rules, redundancies etc. etc. That could save much time
of the learner. The vocabulary should also be well designed,
making use e.g. of the knowledge of the AI people in dealing with
classification of concepts etc. Then the words should be fairly
short, to save writing efforts. Of course, phonetics is also
important; a spoken word should not sound almost the same as
another, thus creating ambiguity. I think that this is possible,
though nobody is likely to have the willingless, funds, time,
and other resources to undertake/join such project which does not
create personal profits. A universal language in this sense could
to be easier to learn than any current natural language by
foreigners by a substantial factor, I believe. On the other hand,
creation of such as a 'standard' language for intercourse of all
people having different native languages is probably next to
impossiblity, if one recalls that in computer programming everyone
has his favourite (so-called 'standard') language, despite the fact
that the programming languages are very much simpler than natural
languages and are designed from the very beginning to have conscise,
rigorous and straightforward rules in aspects of syntax and
semantics and consequently it would be relatively easily possible
to create one universal programming langauge to substitute them all.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Date: Tue, 07 Mar 2000 19:04:07 +0100
Tim Tyler wrote:
>
> Both FSM and cellular automata are capable of simulating Turing universal
> systems - anything one can do, so can the other.
Could you give litterature pointers to doing conversion between
FSM and cellular automata? Thanks.
M. K. Shen
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Decompiling/Tamper Resistent
Date: Tue, 7 Mar 2000 10:58:25 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin wrote:
> > ... We're quickly reaching the
> > point that the sizes involved are close enough to the wavelengths of
> > light that it's soon going to be quite difficult to look at them with
> > optical microscopes no matter how good people are.
>
> Actually, we hit that point some time ago. 0.25 micrometer and smaller
> are very common feature sizes. Those you can't resolve with a visible
> light optical microscope, since it's well below the wavelength even of
> blue light. This is why the masking is done using far-ultraviolet
> light sources.
Sort of true -- keep in mind that the .25, .18, or what-have-you is
specifying the _minimum_ feature size. Not everything is that size,
and depending on the kind of chip you're looking at, quite a few
things may be larger. Right now, you can't depend on seeing
everything, but most chips still have quite a bit that's big enough
to look at. It's quickly getting to the point, however, that almost
the only things big enough to see are going to be things like power
traces, and other such large stuff (and even they generally have
slits cut in them, so they're still no sinecure).
Of course there's also the minor fact that different companies don't
entirely agree on the size of a micron. Particularly companies that
are a bit behind the technology curve tend to round things down, so
to speak -- when they say ".25 microns", they really mean something
like "at least a _tiny_ bit less than .35 microns."
--
Later,
Jerry.
The universe is a figment of its own 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
