Cryptography-Digest Digest #340, Volume #12 Wed, 2 Aug 00 16:13:01 EDT
Contents:
Re: counter as IV? (David A. Wagner)
Re: Plausible Word Generation via Trigram Statistics ([EMAIL PROTECTED])
Re: Pegwit - "Weak" ECC with GF(2^m), m composite? (Frank M. Siegert)
Re: Software in market(ECDSA) ("Joseph Ashwood")
Re: I did do it PROTOCOL: ("Joseph Ashwood")
Re: Has RSADSI Lost their mind? (Roger Schlafly)
Encrypting a String to another String containing only certain characters ("Martin
Claviez")
Re: Security (Mike Rosing)
Q: Quantum dots (Mok-Kong Shen)
Let us have Lattice (wtshaw)
Re: Q: Quantum dots (John Bailey)
Re: Encrypting a String to another String containing only certain characters
("Joseph Ashwood")
Re: Small block ciphers (Mok-Kong Shen)
Re: Elliptic Curves encryption (Doug Kuhlman)
Re: Plausible Word Generation via Trigram Statistics (Mok-Kong Shen)
Re: Q: Quantum dots (Mok-Kong Shen)
Re: Software package locking ("Harris Georgiou")
Re: unbreakable code? Yes (JimD)
Re: Sending Messages in Morse Code (JimD)
Re: MS Word Master Password (Roger Schlafly)
Re: Software package locking ("Trevor L. Jackson, III")
Re: Software package locking ("Trevor L. Jackson, III")
Re: Let us have Lattice (Mok-Kong Shen)
Re: Elliptic Curves encryption ("Trevor L. Jackson, III")
What vulnerabilities do I have? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: counter as IV?
Date: 2 Aug 2000 10:43:24 -0700
stanislav shalunov <[EMAIL PROTECTED]> wrote:
> I agree that spending a lot of time setting up key schedule offers no
> inherent security advantage. But what are some of the block ciphers
> for which your scheme (setting up new key schedule for each block)
> wouldn't impose a lot of overhead?
Skipjack has a very low-overhead key schedule.
Rijndael's is also quite low-overhead.
The DES key schedule is low-overhead in hardware,
but software implementations tend to trade off key scheduling time
for encryption time, so in software key setup is usually slow.
Twofish admits a wide range of implementation tradeoffs between
key setup time and per-block encryption time.
I'm sure there are many others.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Plausible Word Generation via Trigram Statistics
Date: Wed, 02 Aug 2000 17:52:17 GMT
James Pate Williams, Jr. <[EMAIL PROTECTED]> wrote:
> Is the source code public domain? If so, I would like a copy. What
> sort of learning paradigm are you using?
Is so, you better post a link to it. I suspect more than one person
would. (Hint, Hint :)
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Frank M. Siegert)
Subject: Re: Pegwit - "Weak" ECC with GF(2^m), m composite?
Date: Wed, 02 Aug 2000 16:25:08 GMT
On Mon, 31 Jul 2000 13:14:40 -0500, Mike Rosing
<[EMAIL PROTECTED]> wrote:
>I haven't found it yet either. My bet is it's a composite:
>O(2^34 + 2^10 + 2^6). The larger term dominates in any case,
>so I think the largest prime factor is the security limit.
So, are there plans to change Pegwit to make it secure...?
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Software in market(ECDSA)
Date: Wed, 2 Aug 2000 10:55:39 -0700
That question doesn't quite make sense.
ECDSA is a signature mechanism that makes use of Elliptic Curves. ECC
typically applies to a Diffie-Hellman type key exchange taking place under
Elliptic Curves (as opposed to integers). The concepts don't work together
the way your post suggested. However I believe Certicom has toolkits that
are capable of both ECDSA and ECC.
Joe
"Sergio Arrojo" <[EMAIL PROTECTED]> wrote in message
news:8m96ko$r7n$[EMAIL PROTECTED]...
> I would like to look what kind of software is for sale in order to
implement
> ECC with ECDSA.
>
> Sergio Arrojo
>
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: I did do it PROTOCOL:
Date: Wed, 2 Aug 2000 10:52:57 -0700
Easy, choose a good random number, send it to the client in question, if the
client can echo it back in N ms, then a claim that the client has an N ms
ping is verifiable. If you're looking to prove that the client cannot have a
ping lower than N? That's a bit more difficult, but if you choke the pipe
down at the server to an N ping when a client claims an N ping you can force
the client to have a ping of at least N.
Joe
"R Fabian" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Is there any way (protocol) that can be used to prove that a person (in
this
> case game player) has got the ping he says he has. Also, is there any way
> that I can use a protocol to proove that a choice was made before helpful
> data was recieved? By this I mean, is there a protocol that could
eliminate
> the DODGE.BOT scripts. I want to make sure the client decided to dodge
based
> on guess work rather than information.
> Server will be trustworthy, but client will be aggressive cheater. roughly
> all I really need is a system that proves that a network packet was sent
at
> the time it was sent.
>
>
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Wed, 02 Aug 2000 11:00:56 -0700
Sander Vesik wrote:
> FWIW: IMHO NIST should have (had) a separate contest for these. They have
> been caught in the trap of wanting to impose a uniform 'one size fits all'
> crypto standard on everybody. I don'tthink any of those has ever succeeded
> in the long run.
Actually, DES did very well for a long time.
NIST has reserved the option of choosing multiple winners in
case it turned out that no one cipher satisfied all the
requirements. However, it now appears that at least 3 of
them satisfy all the requirements, and perform well in both
hardware and software. If so, any one will do fine.
------------------------------
From: "Martin Claviez" <[EMAIL PROTECTED]>
Subject: Encrypting a String to another String containing only certain characters
Date: Wed, 2 Aug 2000 20:11:38 +0200
Can I encrypt any string to another string that is containing only certain
characters ?
For example I want to encrypt any string and the resulting string should
only contain
numbers or letters and NO special characters like ?,!,^,(,), ... and so on.
Where can I found an algorithm for this task ?
A strong crypt routine is not required but is welcome.
Bye
Martin
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Security
Date: Wed, 02 Aug 2000 13:11:15 -0500
Sergio Arrojo wrote:
>
> When using a curve over a field 2^n with n prime (n big enough). By knowing
> that the curve is not Anomalous and that the MOV condition is satisfied can
> we assure that it is secure. If not what else should we do to be 100% sure?
As pointed out in another thread here, you can never be 100% sure that some
one won't find a way to break any PK system. In general, GF(p) is considered
more secure than GF(2^p). GF(2^p) is faster to implement on an 8 bit
microcontroller. You have to be careful on a microcontroller to watch for
side channel attacks.
Hang in there, it's fun to figure all this stuff out. For a quick education
visit the Counterpane web site and read a few of Bruce's papers. You can
only do so much anyway, the crypto is probably far stronger than the box it
is placed in.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: Quantum dots
Date: Wed, 02 Aug 2000 20:20:54 +0200
I just learned that there is something called semiconductor
quantum dots. Could someone knowledgeable in physics tell
what these are and whether they have anything to do with
quantum computing? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Let us have Lattice
Date: Wed, 02 Aug 2000 11:39:55 -0600
OK, rounds and diffusion from me? Yes, it hurts so much. I see them as a
method, not THE method, and dwelling on binary is not required.
Lattice is a generic block cipher algorithm that exhibits complete
diffusion, changing a character in plain text is most likely to change all
characters in ciphertext. Every character in ciphertext is affected by
all keys used.
Lattice is non-base specific, any base can be used, the larger, the
stronger the keys can appear to be.
Keys are permutations of the base alphabet, the number of which are equal
to the width of the input block, 3 or more characters per block. The
number of iterations is equal to the width of the block. A block width of
2 would require sum and difference logic, but, Lattice uses selective sum
logic.
A round is composed of cross-summing and substitution rereferenced to a
normal set order. For block=4, the cross-summing is w=a+b, x=a+c, y=b+d,
and z=c+d. Inverse functions for B=4 or more are something that you need
to derive yourself.
Block=3 is easier: x=a+b, y=a+c, z=b+c
a=((2N+x+y-z) mod 2N)/2, b=((2N+x+z-y) mod 2N)/2, c=((2N+y+z-x) mod 2N)/2
Ritter suggests that if you want decryption to be faster, encrypt with
inverses, and decrypt with easier functions.
Necessary are the normal character set and B permuted keys.
The diagaram of the thing is obviously a lattice with closed sides.
Binary? Sure thing Joe-Bob, but the keys, the substitutions, give you a
potential strength here that is apt to be quite unpolitically-correct
high. The deal is that you cannot guarantee a bad permutation or weird
interaction of several of them, but you are on your own to make a
reasonable effort at generating the permutations; odds are improbable
against real self-inflicted problems.
The design is too simple to allow hanky-panky at the algorithm level. It
could be done at the key level, but make your own keys.
To get bit-equivalent keyspace, multiply the strength of permutation in
bits by the number of characters in a block: 5 character group @ base 26
is 5*88.38 or 441 bits; base 49 times for 3 character group is 3*208.6 or
625.8 bits.
Of course, there could be more rounds and more keys to be distributed
within rounds. It is a no-brainer to generate as much strength as you
desire, make a block size as big as you dare, and look like you can pile
things higher and deeper than anyone else can or wants.
--
Free Circus soon to appear in Philadelphia, complete with a
expectation of elephants, and noisy clowns in undignified
costumes performing slight of logic, and, lots of balloons.
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Q: Quantum dots
Date: Wed, 02 Aug 2000 18:34:34 GMT
On Wed, 02 Aug 2000 20:20:54 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>I just learned that there is something called semiconductor
>quantum dots. Could someone knowledgeable in physics tell
>what these are and whether they have anything to do with
>quantum computing? Thanks.
Quantum Computation with Quantum Dots and Terahertz Cavity
Quantum Electrodynamics at
http://xyz.lanl.gov/abs/quant-ph9903065
Authors: Mark S. Sherwin, Atac Imamoglu, Thomas Montroy (University of
California, Santa Barbara)
Abstract:
A quantum computer is proposed in which information is stored in
the two lowest electronic states of doped quantum dots (QDs). Many QDs
are located in a microcavity. A pair of gates controls the energy
levels in each QD. A Controlled Not (CNOT) operation involving any
pair of QDs can be effected by a sequence of gate-voltage pulses which
tune the QD energy levels into resonance with frequencies of the
cavity or a laser. The duration of a CNOT operation is estimated to be
much shorter than the time for an electron to decohere by emitting an
acoustic phonon.
this report is referenced and quantum dots are assessed (along side
other proposed quantum computing techniques) in the report:
The Physical Implementation of Quantum Computation
Author: David P. DiVincenzo, IBM
http://xyz.lanl.gov/abs/quant-ph0002077
John
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Encrypting a String to another String containing only certain characters
Date: Wed, 2 Aug 2000 11:34:20 -0700
Of course it's possible. Just do the following:
cipherText = Encrypt(Data, Key);
output(BASE64Encode(cipherText));
That will generate a ciphertext that will have only the characters allowed
in Base64, if you need fewer define your own, if all else fails you can
express it in HEX and get 0...9A...F
Joe
"Martin Claviez" <[EMAIL PROTECTED]> wrote in message
news:8m9o19$63mcg$[EMAIL PROTECTED]...
> Can I encrypt any string to another string that is containing only certain
> characters ?
> For example I want to encrypt any string and the resulting string should
> only contain
> numbers or letters and NO special characters like ?,!,^,(,), ... and so
on.
> Where can I found an algorithm for this task ?
> A strong crypt routine is not required but is welcome.
>
> Bye
> Martin
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Small block ciphers
Date: Wed, 02 Aug 2000 20:54:26 +0200
Mack wrote:
> Mok-Kong.Shen wrote:
> >We are doing at the bit level, aren't we? If one substitutes the known
> >bits into the T terms, how can one say that an expression involving
> >the T terms has T unknowns instead of B unknowns? (Compare
> >my example quoted below.)
> >
>
> Yes it is a bit level representation. The expression is developed before
> we have known bits. Once those bits are known the expression can
> be reduced. ie. without a known pair we develop the expression of
> the cipher in ANF in terms of equations of output with input and
> key being unknown. So we have T unknowns at this point. Once
> we have a known pair we can reduce this to a set of equations in
> K unknowns by substituting the known bits for the B variables.
>
> Now it is conceivable to develop a set of equations for K unknowns
> by assuming a certain plaintext. This results in a chosen plaintext
> attack rather than a known plaintext attack.
Whether known-plaintext or chosen plaintext, the input bits are
known. Hence I would say that in both cases we have B equations
and K unknowns. Theoretically, with more plaintext and ciphertext
pairs, the K unknowns can be solved. Practically, this could be
a different issue. Anyway, I don't know whether useful and general
assertiions could be made that are valid in all situations.
M. K. Shen
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Wed, 02 Aug 2000 13:46:03 -0500
Mike Rosing wrote:
>
> Doug Kuhlman wrote:
> > Overusing a word is a common mathematical problem. I'd love solutions!
> > I tried using postulates for my proofs.... Certainly, assuming your
> > postulates are true is dangerous and that is, so some extent, what PKC
> > does (Course, both RSA and EC are even worse. They're not even shown to
> > be equivalent to factoring or to solving the ECDLP). To my knowledge,
> > only Blum-Blum-Schub (yes, I brought it up) is actually proven
> > equivalent to anything (namely, factoring). Does that mean it's hard?
> > I don't know. Certainly, the mathematics doesn't say so (CAN'T say
> > so...even NP-complete problems use various postulates). I know I can't
> > factor very large n and that the public crypto world can't either.
> > That's good enough for me. If you want more, you're welcome to look,
> > but I doubt you'll find it.
>
> RSA may not be equivelent to factoring, but factoring will crack it.
> ECC seems to me to be just ECDLP, especially for a simple DH like
> transfer. A sub-exponential algorithm for ECDLP would advance a lot
> of mathematics.
>
Agreed. Have you seen a proof that breaking ECDH is equivalent to the
ECDLP? I haven't. I seem to recall a couple years ago, a claimed proof
that breaking RSA was easier than factoring, but I never saw it enough
to make my own judgment. Anyone else know about this?
> Terry is correct to state that these things are not secure from an
> unknown method of solution. It's ballancing the present against the
> future. If you want something secure *forever* you can't use anything.
> Because Terry is right, we simply can't know what will be discoverd
> in the future.
>
Sure! Not denying that. It seems quite likely that most of (PK, at
least) crypto will always be one-way...if you can find the shortest
vector, you can break NTRU. But breaking NTRU might be easier than the
SVP (for example).
> To me, this is an impractical state. I'm willing to bet that any of
> these algorithms is secure for the next few years. That's good enough.
>
For me, too. But what do you mean by an "impractical state"?
> I would very much like to see a scalable cipher. This too would be a
> pretty major advance for the art. But until it comes along, I'll do
> what everyone else does: use ciphers that *look* secure *now*.
>
Actually, most PK ciphers are scalable (in one form or another). It's
one of the reasons they *seem* secure *now*. 1024-bit RSA not good
enough but you think factoring is hard? Use 2048-bit RSA. etc.
Scaling Rijndael, OTOH, to accept 512 bit inputs and a 1024-bit key
seems less trivial....
Doug
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Plausible Word Generation via Trigram Statistics
Date: Wed, 02 Aug 2000 21:24:33 +0200
Kurt Shoens wrote:
> I wrote such a program to generate random words from trigram statistics.
> I train the thing with a dictionary of words and it spits out random
> words for you. Here's an example of what they look like:
>
> election iniopsitism communiform savskillar yorrating destaffoot epidotion
> ratogenous easligory alystely arelaughhea asculpator antarenesis pomologic
>
> Most of the words it creates can be pronounced.
>
I just saw in a post in a mailing list something that is
related in some measure to what you are doing. The author
call it mnemonic encoder. The following is taken from
his web page http://www.tothink.com/mnemonic
The mnemonic encoding presented here is a method for
converting binary data into a sequence of words suitable for
transmission or storage by voice, handwriting, memorization
or other non-computerized means. The encoding converts 32
bits of data into 3 words from a vocabulary of 1626 words.
The words have been chosen to be easy to understand over the
phone and recognizable internationally as much as possible.
Could you look at that scheme and give your evaluation/comparison?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Quantum dots
Date: Wed, 02 Aug 2000 21:24:25 +0200
John Bailey wrote:
> Quantum Computation with Quantum Dots and Terahertz Cavity
> Quantum Electrodynamics at
> http://xyz.lanl.gov/abs/quant-ph9903065
>
> Authors: Mark S. Sherwin, Atac Imamoglu, Thomas Montroy (University of
> California, Santa Barbara)
> Abstract:
> A quantum computer is proposed in which information is stored in
> the two lowest electronic states of doped quantum dots (QDs). Many QDs
> are located in a microcavity. A pair of gates controls the energy
> levels in each QD. A Controlled Not (CNOT) operation involving any
> pair of QDs can be effected by a sequence of gate-voltage pulses which
> tune the QD energy levels into resonance with frequencies of the
> cavity or a laser. The duration of a CNOT operation is estimated to be
> much shorter than the time for an electron to decohere by emitting an
> acoustic phonon.
Thanks. It may be of interest to note that there is currently an
international
conference on quantum dots. I happened to see a number of posters
but the materials in them are of course entirely cryptic for a layman like
me.
M. K. Shen
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: Software package locking
Date: Wed, 2 Aug 2000 22:13:32 +0300
Ian Dichkovsky <[EMAIL PROTECTED]> wrote in message
news:8m91t1$1m6p$[EMAIL PROTECTED]...
> Forget it!
> Crackers and hackers anyway break this protection.
> Even if someone would purchase new serial number, he(she) could
> simple upload to the warez sites.
>
I think you've got it wrong. Since there is the need of retrieving info
about the current hardware, time and storage medium, the hashing must take
place on the client environment - this means that no matter how good the
function is, the code implementation will still be inside the executable of
the application. The basic idea is keep the algorithm and its results away
form the user and provide a way to periodically update the encryption data
WITH the intervention of the user. So, the question is not how secure this
scheme is - a good programmer could disassemble the executable code, remove
the security checks and create a new "freeware" version of it, as you
describe it. This is the reason I do not think that using a very hard
hashing scheme would provide anything at all. I just want to know if anyone
else has tried it, what hardware features did he/she used for creating a key
and in which way these info were retrieved (CMOS, Windows registry, other?).
--
_________________
______/ Harris Georgiou \______
Informatics Systems Analyst
mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (JimD)
Subject: Re: unbreakable code? Yes
Reply-To: JimD
Date: Wed, 02 Aug 2000 18:15:14 GMT
On Mon, 31 Jul 2000 22:20:39 -0700, "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>Except that you still have that same issue of getting the CD
>to the other person securely. You can't tell if I've
>hijacked your Post, read the CD, and dropped it back in the
>post. If you plan on delivering it in person, why don't you
>deliver your information in person too?
You forget that they want to communicate securely over
a period, not to transmit a whole lot of data at once.
--
__________________________
Jim Dunnett.
g4rga at thersgb.net
------------------------------
From: [EMAIL PROTECTED] (JimD)
Crossposted-To: sci.math
Subject: Re: Sending Messages in Morse Code
Reply-To: JimD
Date: Wed, 02 Aug 2000 18:15:15 GMT
On Wed, 02 Aug 2000 02:42:05 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>On Tue, 01 Aug 2000 22:18:42 +0200, in
><[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
>
>>[...]
>>I read somewhere that the Morse code was designed to be
>>optimal for transforming normal English sentences.)
>
>Just maybe that was true of one of the American Morse codes used on
>telegraph circuits for over a century (I have a key-and-sounder
>"learner set" with an American Morse table dated 1960), but what we
>normally think of as "Morse code" is International Morse, as
>standardized in Europe. It is good but not ideal for English.
Why not? There are symbols for the most common punctuation
as well as most accented letters for other languages.
--
__________________________
Jim Dunnett.
g4rga at thersgb.net
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: MS Word Master Password
Date: Wed, 02 Aug 2000 12:15:27 -0700
CMan wrote:
> This scheme simply super encrypts the 48 bytes of key related material in
> the Word Document "1Table" Stream. This is the data that Word uses to test
> a password to see if it is the valid password for the file. ANY corruption,
> even one bit, makes the file recovery essentially impossible because Word
> will take the first 16 bytes of this data and use it as a salt to combine
> with the applied password to get a hash that is then compared with an
> encrypted has stored in the next 32 bytes. If the password does not hash out
> to the correct value, it won't attempt to open the file.
Ok, but wouldn't it be easier and more secure to just re-encrypt
the file with some other scheme? You are just encrypting a small
piece of the file, and counting on properties of MSWord encryption
that are already there.
------------------------------
Date: Wed, 02 Aug 2000 15:33:12 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Software package locking
Harris Georgiou wrote:
> Hello all,
> I have designed a security scheme to for locking non-public domain software
> packages, like expensive commercial packages do with hasp devices, but in
> software level. The basic idea is to use steganographic techniques and bind
> a specific product & it's serial number to each client. The access control
> (keys) are machine-dependant, time-variant and installation-specific. In
> regular time intervals, the client should contact the publisher and update
> it's key.
> However, I cannot find a good way to produce a satisfying key from
> machine-dependant attributes. I have tried CMOS, HD partition table, etc,
> but usable keys seem to be very short in length, since most PCs share common
> characteristics.
> Any thoughts?
One possible area is the BIOS ROM. It is at least 8Kb and there are many
versions available. However, a site that buys computers in bulk from a large
vendor will have many identical machines. In those instances you may also need
to use a unique code such as node address.
The linkage to the BIOS can be arbitrarily tight. In the past I've tied
applications to machines by finding code segments within the BIOS ROM that were
safe to execute. Of course this kind of linkage is severed if the machine is
upgraded.
------------------------------
Date: Wed, 02 Aug 2000 15:37:11 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Software package locking
Ian Dichkovsky wrote:
> "Harris Georgiou" <[EMAIL PROTECTED]> wrote in message
> news:8m8v6a$1grv$[EMAIL PROTECTED]...
> > software level. The basic idea is to use steganographic techniques and
> bind
> > a specific product & it's serial number to each client. The access control
> > (keys) are machine-dependant, time-variant and installation-specific. In
>
> Forget it!
> Crackers and hackers anyway break this protection.
> Even if someone would purchase new serial number, he(she) could
> simple upload to the warez sites.
It is the ego of crackers that drives them to accept challenges like breaking
complicated software protection schemes. That same ego drives them to overstate
the case that _all_ schemes are crackable. The difference is theory versus
practice. In theory counting to 2^256 is possible the practice is a little
harder to manage.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Let us have Lattice
Date: Wed, 02 Aug 2000 21:52:05 +0200
wtshaw wrote:
> OK, rounds and diffusion from me? Yes, it hurts so much. I see them as a
> method, not THE method, and dwelling on binary is not required.
>
> Lattice is a generic block cipher algorithm that exhibits complete
> diffusion, changing a character in plain text is most likely to change all
> characters in ciphertext. Every character in ciphertext is affected by
> all keys used.
>
> Lattice is non-base specific, any base can be used, the larger, the
> stronger the keys can appear to be.
>
> Keys are permutations of the base alphabet, the number of which are equal
> to the width of the input block, 3 or more characters per block. The
> number of iterations is equal to the width of the block. A block width of
> 2 would require sum and difference logic, but, Lattice uses selective sum
> logic.
>
> A round is composed of cross-summing and substitution rereferenced to a
> normal set order. For block=4, the cross-summing is w=a+b, x=a+c, y=b+d,
> and z=c+d. Inverse functions for B=4 or more are something that you need
> to derive yourself.
>
> Block=3 is easier: x=a+b, y=a+c, z=b+c
> a=((2N+x+y-z) mod 2N)/2, b=((2N+x+z-y) mod 2N)/2, c=((2N+y+z-x) mod 2N)/2
I have difficulty to understand why you wrote things like
'(2N+x+y-z) mod 2N'. Isn't that identical to '(x+y-z) mod 2N',
which is simpler? Further, would '((x+y-z) mod N' be as good
for encryption purpose as your '((x+y-z) mod 2N)/2' ?
Finally, it is a linear transformation. Could you say what
is its advantage over the Hill cipher? Thanks in advance.
M. K. Shen
------------------------------
Date: Wed, 02 Aug 2000 15:42:33 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Roger Schlafly wrote:
> "Trevor L. Jackson, III" wrote:
> > There appears to be a difference between domains that permit experimental
> > XpXrXoXoXfX confirmation and those that do not. Sciences do this. Is it your
> > position that crypto supports experimental confirmation of strength?
>
> You are zeroing in on the difference between mathematics and
> the sciences. You can approach crypto from either view. Both
> views have merit. But keep in mind that there is a huge difference
> between these statements:
>
> (1) Crypto protocol X has been proven secure.
> (2) Experimental evidence indicates that X is secure.
What evidence can we conceive of that will fit into (2)? Note that we're discussing
experiments, which implies repeatability. Historical factors (lack of weakness
detection over periods of time) do not count as experiments.
------------------------------
From: [EMAIL PROTECTED]
Subject: What vulnerabilities do I have?
Date: Wed, 02 Aug 2000 19:36:20 GMT
I've implemented network data encryption of an client/server application
where I use 3DES to encrypt all the data between the client and server.
Let's assume that I have a secure way for the client and server to both
generate the 3DES key without sending the actual key across the network.
I know that I have atleast 2 compromises:
1) if the attacker cracks the symmetric key
2) if the attacker uses a man-in-the-middle attack
Do I have any other vulnerabilities that I've missed?
Thanks for any help
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
