Cryptography-Digest Digest #267, Volume #11 Mon, 6 Mar 00 17:13:02 EST
Contents:
Re: ascii to binary ("Douglas A. Gwyn")
Re: Best language for encryption?? (Gautier)
Re: Excel password remover ([EMAIL PROTECTED])
Re: The Voynich manuscript ("Douglas A. Gwyn")
Re: math error? NOT AT ALL ... (Xcott Craver)
Re: Decompiling/Tamper Resistent ([EMAIL PROTECTED])
Re: Decompiling/Tamper Resistent (John Savard)
Re: Decompiling/Tamper Resistent ([EMAIL PROTECTED])
Re: Decompiling/Tamper Resistent ([EMAIL PROTECTED])
Re: Crypto.Com, Inc. (Mok-Kong Shen)
Re: why xor?(look out,newbie question! :) (Mok-Kong Shen)
Re: Encryption product for IBM mainframes ("Thierry FALISSARD")
Re: Cellular automata based public key cryptography (Xcott Craver)
Re: Cellular automata based public key cryptography (Mok-Kong Shen)
Re: why xor?(look out,newbie question! :) (Mok-Kong Shen)
Oh .. I forgot to mentioned .. my close one in 1999 went to the Federal ("Markku J.
Saarelainen")
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (Adam Back)
Actually, this training session in the Federal Building (Atlanta) as I ("Markku J.
Saarelainen")
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Mon, 6 Mar 2000 18:23:16 GMT
"Robert P. Rumble" 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.
There are several character-coding standards, including at least one ISO
standard that embeds 7-bit ASCII in an 8-bit code, the higher values
being used for various European characters such as the "slash-O", the
"umlauted A", the "c with cedilla", etc. The most prevalent such code
is usually called "Latin-1".
------------------------------
Date: Mon, 06 Mar 2000 20:51:25 +0000
From: Gautier <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
[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.
--
Gautier
_____\\________________\_______\_________
http://members.xoom.com/gdemont/gsoft.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Excel password remover
Date: 6 Mar 2000 20:14:42 GMT
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 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]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The Voynich manuscript
Date: Mon, 6 Mar 2000 18:41:05 GMT
[EMAIL PROTECTED] wrote:
> Conclusion
> The terms of the Voynich manuscript are built from synthetic
> rules which exclude the assumption from the use of a natural
> language for its writing.
>From the detailed article, it appears that you merely fit a
statistical model to the Voynich text, abstracted a few rules
from the result, then applied the rules *yourself* to generate
synthetic text. The same could be done for any body of text
written in any natural language, so you have *not* shown that
the VMS cannot be using a natural language.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: math error? NOT AT ALL ...
Date: 6 Mar 2000 20:47:29 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
>Anton Stiglic wrote:
>
>> If you have a password system where a password is composed
>> of 10 items, each item having 4 chars, then the total amount of
>> different passwords that may exist in that system is 4^10, that
>> is 4*4*4*4*4*4*4*4*4*4 = 4^10 (an *not* 4x10).
First, you misinterpreted the post before you: a string of 10
4-character passwords admits as many possible combinations as a
single 4x10-character password. They offer the same security.
The poster didn't mean that there were only 40 passwords in
the entire space. Tho, he _said_ keyspace, and he seems to have
misinterpreted the post before him---I guess there's some
confusion about the meaning of "keyspace."
Secondly, the formula isn't 4^10, but (n^4)^10 = n^40, where
n is the number of values a single character can take in a
password.
>To clarify, if the initial poster was saying that a password is composed
>of 10 items, where each item is a concatenation of 4 chars, where each
>char has c bits long, then the total amount of possible passwords is
> (2^(4*c))^10.
== (2^c)^40 == n^40, if every character could be used.
Almost right: chances are c==8, but you can only use < 128
possible values.
>> And a final thing, nPr = n!/ (n-r)!*r!
>> I can't explain you that here, you need any descent calculus book
>> for that.
>
>Sorry, I got caught in the mistakes. nCr = n!/(n-r)!*r!, that's not the
>definition of nPr.
Not that nCr or nPr have anything to do with this computation.
Since you're allowed to use the same character multiple times,
the space is just n^m, no fancy permutations and combinations.
-X
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Decompiling/Tamper Resistent
Date: Mon, 06 Mar 2000 21:04:30 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > I am refering to your post and the above poster. It appears that
you
> > dont have a clue of real crypto systems. Have you heard of FIPS-140
> > levels 1-4. Most crypto manufacturers have a
> > tamper-resistent/tamper-proof module (for keys and programs). This
is
> > not to stop customers having access to the source code...customers
dont
> > go snooping around bits of hardware and disassembling code.. There
is
> > an easier way of getting the source code.. You just ask...Isnt that
> > simple..
>
> You didn't state FIPS 140 as your reason for asking, you stated
> concern about decompiling as your reason. The answers you received
> were exactly correct for the latter. In fact, you specifically
> indicated that you want people not to be able to see your software,
> so why do you now say that all they have to do is "just ask" to
> see the source code?
>
We dont want copycats to see our source code..not customers...we would
be pleased to show any customer our source code..There is a difference
between the two..
> For the former, yes, there are some pieces that need to be protected.
> The code needs only integrity, not confidentiality. The only thing
that
> needs confidentiality is a key encipherment key or analogous thing.
Yes
>
> > And I would aprreciate that you dont answer threads about a subject
you
> > know little about...
>
> Insulting your respondents when they answer the question you
> asked rather than the question you later say you *meant* to
> ask isn't going to get you very far... Especially when the
> two are diametrically opposite.
>
The respondent confused two issues in his mind....algorithm security vs
confidentiality...it is obvious to any serious crypto person that
algorithm security does not come from keeping their algo
secret....although some crypto companies still like to think so...and
the intention behind a tamper resistent module is not that...its as a
first level defence to stop copycats...
Infact we are using bog standard ciphers and DH in our crypto system...
A tamper resistent module is pretty much the same wehther its for key
escrow or to keep a crypto application...
I would suggest that tamper resistent modules are much more widely used
then is generally known. Crypto manufacturers use it frequently, but
also the major defence contractos use it too...perhaps thats why its a
black art shrouded in secrecy...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Decompiling/Tamper Resistent
Date: Mon, 06 Mar 2000 14:12:01 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote, in part:
>If you want real protection, there are some rather special
>passivation layers that can be used on chips that do some good -- I
>don't know of any that absolutely CAN'T be worked around, but some of
>them can certainly make life a LOT more difficult.
I should have perhaps mentioned that I either remembered a posting
some time back or read in a book somewhere about some of the measures
rumoured to be used by the military. Chemicals can be painted over the
chip that will burst into flame when exposed to air - or react with
water, and so on. And, naturally, serious protection against EM
emissions is needed.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Decompiling/Tamper Resistent
Date: Mon, 06 Mar 2000 21:09:59 GMT
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > Tamper-resistance is sometimes done in industry by putting chips in
> > potting compounds; I've heard a substance used by dentists is quite
> > good; but I'm not sure that chipmakers offer this sort of thing to
> > commercial customers.
>
> Potting compound will only barely slow down a serious attempt at
> reverse engineering a chip. Just for example, most automotive engine
> control modules are potted to help physical integrity in a rather
> hostile environment. The company I work for has torn into these on a
> fairly regular basis for years.
>
What materials do you use for potting?...some kind of a coating ..or is
it more substantial...are there no serious corrosive effects ...or chip
mulfunction...
> If you want real protection, there are some rather special
> passivation layers that can be used on chips that do some good -- I
> don't know of any that absolutely CAN'T be worked around, but some of
> them can certainly make life a LOT more difficult.
>
Can you explian a little more what you mean here...Passive layers???
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Decompiling/Tamper Resistent
Date: Mon, 06 Mar 2000 21:11:40 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] wrote, in part:
>
> >In order to protect our intelectual property (software) from
decompiling
> >freaks, we need to build our crypto software in a tamper resistent
> >device for our network crypto cards.
>
> You may indeed need to do this to protect software from being copied,
> but you don't need to do it so that you can do encryption securely -
> publicly known algorithms can do this.
Yes fully agree...we are only using it to protect from copycats....we
are using public algorithms...3DES and DH
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crypto.Com, Inc.
Date: Mon, 06 Mar 2000 22:27:36 +0100
Xcott Craver wrote:
>
[snip]
> tapped. So in real-world, large-scale communication systems,
> you must still rely on encryption for quantifiable privacy.
[snip]
Thanks for the valuable informations.
I have a number of questions (or perhaps fancy thoughts):
1. One can split a message into a number of streams and
utilize the CDMA to send these parallelly. It seems plausible
to me that that does render the analysis a little bit difficult.
A method which is also an application of the spread sprectrum
technique bears the name LPI (low probability of interception).
Is it possible to compare these schemes in global terms in
respect of crypto?
2. There are two variants of spread spectrum thecniques, the
DS (direct sequence) and the FH (frequency hopping). Which
one would be preferable for crypto use?
3. The bandwidth is an interval of frequencies centered around
a certain central frequency. How large is such an interval
for spectrum techniques in practice? (One has to get a license
for that, right?)
4. Frequency hopping hops within a rather limited bandwidth.
Following the same idea, I suppose one could also hop on
a global scale. I mean, if there are a number of transmitters
each operating on a specific but separated bandwidth, one could
also hop among these transmitters. Would there be technical
difficulties for realizing that?
5. Following the idea of frequency hopping, I recall an idea that
was previously discussed in this group, namely the use of
multiple algorithms. One can dynamically switch between
different encryption algorithms, thus doing 'algorithm hopping'.
Wouldn't it be a good idea that one combines spread spectrum
techniques with the use of several transmitters and multiple
algorithms?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Mon, 06 Mar 2000 22:31:28 +0100
r.e.s. wrote:
>
> A small slip: You forgot to say that A and B are assumed to be mutually independent
>-- the general result doesn't hold otherwise. (And that's the technical meaning of
>Guy's proviso "not derived from".)
Thanks for pointing out the fault of not having mentioned the
essential assumption of independence.
Incidentally, I tried sometime ago to find some concrete
algorithm or code with which to test the independence of two
bit sources, but sofar without success. I should be very
grateful, if someone could provide a reference or a hint.
M. K. Shen
------------------------------
From: "Thierry FALISSARD" <[EMAIL PROTECTED]>
Subject: Re: Encryption product for IBM mainframes
Date: Mon, 06 Mar 2000 21:26:52 GMT
There are advantages in using our product over IBM's crypto processor.
For example :
- Blowfish's key-length is much longer than DES or 3DES (up to 448 bits)
so you may think it's stronger - and it's fast !
- we have interfaces with other software products : REXX, DB2, DFSMSdss
(disk or file backups) - IBM does not have anything easily usable (which is
a pity, because for example encrypting backups is a frequent need)
- we can interoperate with some PC products, I'm not sure IBM
can (except within its range of PC products ?)
- we also think our encryption utilities and subroutines are more versatile.
IBM crypto processor installing is often deemed a headache.
We are not against IBM's crypto processor, we even intend to
have support for it just to make 3DES encryption faster... IBM's crypto
core is one thing, making it usable for high-level applications
is another thing. I would happily let the core to IBM and
build around it something more accessible for the end-user ...
Of course IBM crypto proc is nice for its speed, key management
(we plan to have a key management feature based upon RACF)
low-level interfaces (SSL), etc. I have much respect toward it.
Thanks for having asked !
http://os390-mvs.hypermart.net/megaceng.htm
===============================================================
>Mark Currie says...
>>
>
>IBM OS/390 enterprise servers already have a built in crypto service. From
the
>G5 upwards, they have a FIPS140-1 level 4 certified hardware crypto
processor.
>I see from your web site that you do offer other features such as Blowfish
and
>being able to integrate with other apps, but I am curious as to why you do
not
>use the inherent crypto core ? Are you mainly intending to sell to users of
old
>mainframes ?
>
>Mark Currie
>
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Cellular automata based public key cryptography
Date: 6 Mar 2000 21:28:17 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
>Dr. Yongge Wang <[EMAIL PROTECTED]> wrote:
>: Tim Tyler ([EMAIL PROTECTED]) wrote:
>
>: : Both FSM and cellular automata are capable of simulating Turing universal
>: : systems - anything one can do, so can the other.
[snip]
>: You may recall that: FSM << pushdown automaton (context-free language)
>: << Turing machines (r.e. language) :-)
>
>All the systems discussed can perform the same types of calculations.
>In reality there is no such thing as a system with infinite storage.
Not this old saw again.
A Turing machine doesn't need infinite storage, just
inexhaustible (i.e., arbitrarily _expandable_) storage. Your
real-world computer is like a Turing machine because you can
always increase storage capacity as it is needed (by buying more
disks, disk space, etc.)
FSMs have their memory size (and "program") fixed right from the
start. That's why we don't use them to model general-purpose
computers.
You could always argue that there is only a finite amount of
memory in the universe, with only a finite amount of atoms at
our disposal. But then you're no longer being realistic: in
reality, the storage available to your computer greatly exceeds
what it needs to do any useful computation.
-S
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Date: Mon, 06 Mar 2000 22:59:49 +0100
[EMAIL PROTECTED] wrote:
>
> >
> >Dr. Wang is exactly correct. However, it is possible to define a
> universal cellular automata (CA) such that given the code of a CA "B"
> and input "x" it can simulate the behavior of "B" on input "x". Both
> this universal CA and a turing machine (TM) cab be proven equivalent
> (i.e. of the same power) via Roger's isomorphism theorem. To see how
> this is done go to http://alife.santafe.edu and then, if I remember
> correctly, to "CA" then "topics" then "faq" then "properties" then
> "computability".
>From the big difference in power, it seems that the universal
cellular automata is quite different from the ordinary cellular
automata, right? Could you please give a few salient features of
the universal one, just for having some rough ideas? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Mon, 06 Mar 2000 22:59:43 +0100
John Savard wrote:
>
> XOR is to be preferred to addition modulo 65536, though, because some
> computers are designed so that the "first" byte of two bytes is the
> least significant part of a number instead of the most significant
> part, so that using addition over a larger item than a byte creates
> the need to define what one is doing more explicitly.
I thought that were already the past. Which are the typical
manufacturers of the two different groups today?
M. K. Shen
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.ukrainian,soc.culture.nordic,soc.culture.europe,soc.culture.british,soc.culture.soviet,soc.culture.baltic,alt.security
Subject: Oh .. I forgot to mentioned .. my close one in 1999 went to the Federal
Date: Mon, 06 Mar 2000 21:56:18 GMT
Oh .. I forgot to mentioned .. my close one in 1999 went to the Federal
Bulding in Atlanta to get some training for some HR management ..
hhmmmmm .. isn't this very interesting .. you know what has been going
and ... :)
------------------------------
From: Adam Back <[EMAIL PROTECTED]>
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: Mon, 06 Mar 2000 16:56:36 -0500
David Hopwood wrote:
> The most obvious, and a robust way of doing this is to append a MAC,
> with an output length of n bits. In principle it might be possible to
> combine the authentication with the encryption for performance reasons,
> but previous attempts at doing that (e.g. PCBC, iaPCBC, CBCC) have
> not been resounding successes from a security point of view.
What is iaPCBC? or is this a typo?
PCBC is Propagating Cipher Block Chaining mode (as used by Kerebos -- like
CBC except previous plaintext block is xored in as well)
CBCC is Cipher Block Chaining with Checksum mode (like CBC except running xor
of previous plaintext blocks is xored in)
PCB is Plaintext Block Chaining (like CBC except previous plaintext instead
of previous ciphertext is xored in).
Adam
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.ukrainian,soc.culture.nordic,soc.culture.europe,soc.culture.british,soc.culture.soviet,soc.culture.baltic,alt.security
Subject: Actually, this training session in the Federal Building (Atlanta) as I
Date: Mon, 06 Mar 2000 22:03:03 GMT
Actually, this training session in the Federal Building (Atlanta) as I
recall was one of Al Gore initiatives for human resource management ... I
mean how low can the USA government go ...? .. can you go lower ... ? The
training was in the first part of 1999.
"Markku J. Saarelainen" wrote:
> Oh .. I forgot to mentioned .. my close one in 1999 went to the Federal
> Bulding in Atlanta to get some training for some HR management ..
> hhmmmmm .. isn't this very interesting .. you know what has been going
> and ... :)
------------------------------
** 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
******************************
