Cryptography-Digest Digest #183, Volume #12 Sun, 9 Jul 00 12:13:01 EDT
Contents:
Re: Concepts of STRONG encryption using variable base (David Blackman)
Re: Proposal of some processor instructions for cryptographical applications
("Kasper Pedersen")
Re: Proposal of some processor instructions for cryptographical applications
("Thomas Womack")
Re: Efficient algorithm to determine relative primality? (John Savard)
Re: Efficient algorithm to determine relative primality? ([EMAIL PROTECTED])
Re: AES: It's been pretty quiet for some time... (David Hopwood)
Re: Any crypto jokes? (potentially OT) (David Hopwood)
Re: Porting Keys Between PGP, other Apps (David Hopwood)
Re: Proposal of some processor instructions for cryptographical applications (Holger
Bettag)
Re: Using CRC's to pre-process keys ("Adam Durana")
Re: Proposal of some processor instructions for cryptographical applications
(Holger Bettag)
Re: Using CRC's to pre-process keys (Nicol So)
Re: Concepts of STRONG encryption using variable base ("Trevor L. Jackson, III")
Re: computer program: extract consonants/vowels from input (wtshaw)
Re: Concepts of STRONG encryption using variable base http://www.edepot.com/phl.html
(Paul Schlyter)
Re: Concepts of STRONG encryption using variable base (Paul Schlyter)
Re: A thought on OTPs ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: Concepts of STRONG encryption using variable base
Date: Sun, 09 Jul 2000 21:29:49 +1000
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > > We all know that encryption these days are weak. Weak in the sense
> > > that they are static and can be brute force searched by permutating
> > > through the keyspace of the encyption key.
> >
> > No they cannot. Use your virtual calculator to figure out how long
> it would
> > take you to _count_ up to 2^256. Then figure out how much slower
> trial
> > decryption is compared to counting. A 256-bit key cannot be searched.
>
> This is actually a very interesting statement. Any static keylength
> can be searched through. The variable you are more concerned with
> is the time required to do it. To answer that one, I give you
> two URLs...
>
> http://www.distributed.net
Yes, the time required to do it is what we are concerned with. Searching
a 256 bit key by brute force with current computers would take longer
than the age of the universe, even if you got every compuer on the
planet working on it.
Other posters on this thread have suggested you go and learn some
cryptography before trying to tell us we are all wrong. Before learning
cryptography, i suggest you first go and learn to do simple arithmetic.
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Sun, 09 Jul 2000 12:01:12 GMT
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I implicitly assume a common processor, e.g. what people normally
> have access to, e.g. a PC.
Aren't we already talking specialty items? Maybe people _will have_, but
they certainly don't _have_
> The problem is with the size of the look-up table and quite probably
> also the efficiency incurred thereby in case the permutation is
dynamically
> determined so that one has to recompute the look-up table frequently.
Which is acceptable on fixed perms. A 32:32 mapping can be done in 4 clks on
a modern CPU, the 16 kbit memory for the table the limiting factor as we
assume 1 load per clock. But - that memory isn't much bigger than the 32:32
switch matrix on the silicon, and it's a lot more powerful.
Dynamically changing perms of this kind are fun - but you can probably find
something that's more cryptographic value for the cost.
> Perhaps I misunderstood you. But it is not a matter of formal formulation,
> it is a matter of implementation (with processor instructions).
Which is why he's talking FIR filters. DSPs have special instructions for
those, optimized to such a degree that they sometimes take up most of the
silicon. Take the sample C code below
for (i=0; i<n; i++)
{
acc+=data[p1+base_p1]*data[p2+base_p2];
p1=(p1+1) mod size_p1;
p2=(p2+1) mod size_p2;
}
A typical low-cost DSP will do the above loop in 1+n clock cycles. The above
{...} is one instruction in the CPU, and the for(;;) is free (typically 1
clk setup).
And with a little headache, it can be implemented in 3DNow! at 1 clock/round
v. 32*32, for those running K6-x or K7's.
Notice how well it moves bits around?
/Kasper
------------------------------
From: "Thomas Womack" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Sun, 9 Jul 2000 12:37:42 +0200
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote
> Transposition is one of the basic operations in cryptography.
Is it, any more? Having a look at the AES candidates, most of them carefully
refrain from calling for bit transpositions simply because they're rather
hard to implement.
If you want byte transpositions, Altivec has a vector-permute instruction
which considers one 128-bit register as a list of 16 bytes A[0..15],
considers the lower bit of each byte as an index into a second register B
(also considered as a set of 16 bytes B[0..15]), and sets C[i] = B[A[i]]. I
don't know how long this instruction *takes* on a current G4, but someone in
comp.arch surely does.
The bit scatter/gather technique you suggest seems to go very against the
RISC philosophy by having a single instruction require hundreds of memory
operations; I think you have to stick with permutations that can fit in a
register, though there's nothing stopping you from suggesting a
super-Altivec using 256-bit vector registers.
If you don't mind a lower granularity, the Pentium 3 has instructions which
can arbitrarily shuffle an array of 4 shorts or ints or floats (the Athlon
can only do this for shorts at the moment), though this is based on an
immediate operand rather than a register.
Swapping small sections of words isn't that painful:
C = 0xf0f0f0f0;
A = X & C;
B = X & ~C;
X = A|B;
and its obvious extensions. I can get bit-reversal of a 64-bit number to run
in 24 ticks on a K6/2 without even trying, and I don't expect it to take
much over 50 ticks to bit-reverse three 64-bit numbers in parallel.
> Another processor instruction that I think is desirable is
> to obtain the parity of groups of bits (e.g. 4, 8, etc.) from
> consecutive words in memory and accumulate these into a word.
Why not rearrange the problem (especially if you're using a bit sequence
with lots of entropy to begin with), assume some nice person has transposed
the bit matrix for you, and just do V = U[0] ^ U[1] ^ U[2] ^ U[3]?
Tom
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Efficient algorithm to determine relative primality?
Date: Sun, 09 Jul 2000 12:52:29 GMT
On Sun, 09 Jul 2000 18:06:21 +1200, "ben handley"
<[EMAIL PROTECTED]> wrote, in part:
>> Actually, Euclid's method is better than polynomial time, and you won't
>> find one much faster. It would take a time proportional to the logarithm
>> of the number of digits in the number if the time for addition and
>> subraction were constant, and this is very good speed.
>Hmm, are you sure of this? I thought it was proportional to the logarithm
>of the numbers, i.e. proportional to the number of digits. Are you saying
>that you can find the gcd of two 1000 digits in order 10 iterations?
You're right: I am mistaken. It cuts the number in half or so at each
step, not the size of the number.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Efficient algorithm to determine relative primality?
Date: 9 Jul 2000 09:08:05 -0400
ChenNelson <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Would someone know an efficient algorithm for determining whether
> numbers x and y are relatively prime, without havng to necessarily
> calculate gcd(x,y) using Euclid's method? Calculating the gcd of two
> numbers using Euclid's method is too slow for crypto-size (100+digits)
> numbers. Thanks.
Too slow? UBasic can find GCDs quite quickly using the Euclidean algorithm
(and it supports over 2,000 digits in its integers).
------------------------------
Date: Sat, 08 Jul 2000 18:53:48 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: AES: It's been pretty quiet for some time...
=====BEGIN PGP SIGNED MESSAGE=====
John Savard wrote:
> On 5 Jul 2000 11:43:22 GMT, [EMAIL PROTECTED] (Mark Wooding) wrote, in
> part:
>
> >No. IBM changed policy in round 2: MARS is free for all uses. See the
> >round 2 MARS intellectual property statement.
>
> Couldn't quite find it on the NIST site. Not sure where to look.
http://csrc.nist.gov/encryption/aes/round2/AESAlgs/MARS/mars-ip-update.pdf
and
http://www.tivoli.com/news/press/pressreleases/en/2000/mars.html
(You can find information like this for many algorithms at
http://www.users.zetnet.co.uk/hopwood/crypto/scan/)
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOWdqLDkCAxeYt5gVAQESTQf/bHSdNl1uXSsSfRi5qRP10WXNCxdVtmws
1rYFbsd1qnZ2bhnz6p+KfS0GtTvPBb1yKvmi3WJ9uoYeq5MxyGuap/SwOH0Gepr2
vny+KQ3nqWkRgQcJus4fAou4YhAII9uK5OuVa+K88UNkE3GwUNyRQkzY2czu/OPY
9J334xgHwMDVcM6B0UzFlCnaYRtEMKUx/qBXBK00IL+lJ1ivUZKSSnozHr+xRioM
OG8dfoWD4YjsESRLNwmdbnJqEhnVqwSDKkftF8zCMrQKawgGdLy783ogHGQ9YIdc
criU9iewDdZo3Hdrj+/sRmGpNZaNy+x47TDnrubUyW9Op28tftbAJw==
=efVG
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 08 Jul 2000 22:33:34 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Any crypto jokes? (potentially OT)
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> How many cryptographers does it take to change a light bulb?
Three: one to change the lightbulb, one to present a paper on how changing
lightbulbs can't be done, and one to sweep the room for NSA listening devices.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOWeeFTkCAxeYt5gVAQFGHggAgcmTehh3sVOSqZYQWLAv5uO/Ueui7tRy
ulZxyhbD69dqh4bKog9DohA5/XQUIDJArQ/glqUjJRYwMlTiwRqIomPVKVxn6Ckq
UivmAfQVUuKUijtXjTAHYUoQpciLhrfAE2czUx9EM8xPkgy5mntyBuwlEL24v6Je
IhTG2+qXnRK1jrLlASrkTfZc77IVmazBnxldtWdE4d3IChC4XnvDEoKJ9FEuKs3n
yu5sd1Ms0CZkL8Pz8g/3/VcfH6XrrcoSwKyGDLdKVtQ5L7zPWFbs1/mmz/qV5EvX
1QJfshXmZnsoYfwmB5DjmJ6dO4LzMXbM3avtQucL4ZFxRK8CN66wXA==
=GNoD
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 08 Jul 2000 23:30:50 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp
Subject: Re: Porting Keys Between PGP, other Apps
=====BEGIN PGP SIGNED MESSAGE=====
Ed Suominen wrote:
> Can you port an RSA private/public key pair between PGP and other
> applications?
You can, but don't (unless the other applications specifically implement
OpenPGP).
Transferring keys between standards is generally a bad idea, because any
weakness in one standard may expose messages sent in the other. Also,
users normally won't have any software that allows them to verify that
the key material used in one standard is "the same" as in another, so
it's fairly pointless.
If the issue is to transfer trust in a (public signature key <=> identity)
association between standards, you can generally do this much better by
signing an exported form of the key that you want people to trust, with
the key that they already trust, as an ordinary message using the
conventions of the latter key's standard.
For example, if you wanted to certify your OpenPGP key in a way that
can be verified by someone who already knows your S/MIME key (or
whatever), export the OpenPGP key in its ASCII-armoured form, add some
text describing what you're trying to do (at a minimum, something like
"This is my OpenPGP public key"), and sign that with the S/MIME key using
S/MIME software. You can also do the same in the other direction.
This works for signature keys. Encryption keys should ideally be self-
certified using a signature key (OpenPGP supports this quite well; X.509
doesn't).
[...]
> Can anyone shed light on this and why the PKCS #7 "thumbprint" is
> different from the PGP "fingerprint" when its the same exact RSA key?
There are three reasons:
- the "thumbprint" for PKCS #7 is a hash of the certificate, not the key
(certificate hashes are pretty useless IMHO, but there you go),
- different hash algorithms are used (in this case, your X.509 software
is using SHA-1 and PGP is using MD5),
- even if the hash functions were the same and both standards were hashing
the key, they would probably use different representations of it.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOWerODkCAxeYt5gVAQEhHAgAw/TZZrmSQ+TTOT7hjnnCTsQSy76tTqze
o5F9GfmRFieJ1vxyR+wZXoHHNqf5KBwAjw23JWz89wSs5Ct1gDT7Q+2JYtO9rB0a
sTFChpq6IwYxsEDZI05T5ltzpJOJB2nqKL8e+r2aPjXn9ysttljJtoB7/AJVdH+H
RmUd0IjpICADuOfbIi5GDd61cqGtwSpp/QGpTHtEXwumchyjOeRCHWqQgmLU5jzW
5Lsz/TRDYLekTqi5XUV399MjLmM2S5+9XVX5lgWQGA1aAGFYDNyQpgET3hZ+lw4N
Auafe5B2iCWshVSq7ltqSFzMfdWd8BOM9QCcjZ3lrzCFYEIhMkQ+lw==
=YdHz
=====END PGP SIGNATURE=====
------------------------------
From: Holger Bettag <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 09 Jul 2000 16:51:17 +0200
"Thomas Womack" <[EMAIL PROTECTED]> writes:
[...]
> If you want byte transpositions, Altivec has a vector-permute instruction
> which considers one 128-bit register as a list of 16 bytes A[0..15],
> considers the lower bit of each byte as an index into a second register B
> (also considered as a set of 16 bytes B[0..15]), and sets C[i] = B[A[i]]. I
> don't know how long this instruction *takes* on a current G4, but someone in
> comp.arch surely does.
>
Vector permute is documented to have a latency of 1 cycle and a throughput of
one per cycle on a PPC7400.
Somewhere in Moto's documentation there is example code on how to do arbitrary
128 -> 128 bit permutations. AFAIK you need to preload 8 vector registers with
byte-permutation info, and 8 more with bit-permutation info. Then you can do
one such permutation in, I think, 24 clock cycles (one vector permute, one
bitwise rotate of a byte vector, one bitwise vector select; for each of the
8 bits of the output bytes). You can probably accelerate this by sacrificing
8 more vector registers for constant masks (for the select operation), which
should bring the timing closer to 16 clock cycles per permutation.
Holger
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Using CRC's to pre-process keys
Date: Sun, 9 Jul 2000 10:49:54 -0400
> I believe what he was trying to say is that if you take a SHA-1 for
example
> and produce a 128 bit value (pick your method of reducing it) from a 128
> bit input you will have some collisions. By the birthday paradox 1
> collision after 2^64 inputs. With a CRC for a fixed 128 bit input length
> you will never get a collision unless you reuse an input.
>
> Is this any clearer?
Yes its clear now, but are you sure this is true about CRC? I know there is
quite a bit of mathematical theory behind CRC, but I was unaware that you
were guaranteed no collisions if you used input of the same size as the
output. And if what he said about the entropy of the output being the same
as the input, and you are using an input and an output of equal size, what
is the point of using CRC at all? The only time I can think of where it
would be useful to use a hash function to pre-process a key would be when
the data provided for the key is user input, e.g. something the user can
remember like a string of text. In which case CRC probably wouldn't be any
better than other secure hash functions because it is most likely that the
input will not equal exactly 128 bits. And if it did equal exactly 128 bits
the CRC of that input, assuming the statement about the entropy of the
output of CRC is true, the CRC'ed key would be no better than the original
key.
- Adam
------------------------------
From: Holger Bettag <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 09 Jul 2000 16:53:21 +0200
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> Skipper Smith wrote:
>
> > Have you looked at the AltiVec instructions contained in the MPC7400? You
> > can download the manual from:
> > www.mot.com/SPS/PowerPC/teksupport/teklibrary
>
> It would be nice, if you would give a list of instructions of that processor
> that are particularly relevant for crypto.
>
"Vector permute" would be the most outstanding candidate. Together with
"vector select" and the bitwise shifts/rotates, one can build almost arbitrary
bit permutations.
Holger
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Using CRC's to pre-process keys
Date: Sun, 09 Jul 2000 11:00:10 -0400
Reply-To: see.signature
[Context: I asked David if he had an attack in mind that's effective
against using CRC to "distill" randomness for the purpose of key
generation.]
"David A. Wagner" wrote:
>
> Well, here's one. It's not a good example, because it requires a
> funny assumption, favorable to the cryptanalyst and highly unrealistic.
> But it's the best I can come up with at the moment.
>
> Consider a continuous system that has a bunch of inputs (mouse, timer,
> network, hard disk timings, ...) and will generate a key on demand by
> sampling all its input ports and computing the CRC of its inputs,
> whenever requested. Suppose the attacker has control over one of
> those inputs. Suppose also that the attacker can cause new keys to
> be generated whenever he likes, and can get chosen plaintexts encrypted
> under those keys.
The designer of such a system needs to have a good estimate for the
minimum rate the system can harvest entropy, taking into account what an
active adversary may be able to do. (Actually he needs to do that for
each of the entropy sources used). The system must not allow an
adversary to have enough influence over the entropy sources as to make
the harvested entropy fall below what is required by the application.
When I asked the question, I assumed that the issue was taken care of.
The scenario you described is certainly possible, but it should not
happen with a properly designed system.
As for the part that the adversary can trigger key generation and
control the plaintext, it is realistic enough. It can happen if the
system is a server that responds to requests automatically.
> Then the attacker can try the following attack: ask for a key K to be
> generated, then tweak the one input he controls by xor-ing it with a
> known difference D, then ask for a new key K' to be generated. If the
> attacker is lucky, maybe none of the other inputs changed in between
> the two requests. If that is so, the linearity of the CRC ensures that
> K,K' will have a known difference D', where D' = CRC(D). In other words,
> we can predict that K' = K xor D will hold, even though we don't know
> K or K' directly.
>
> But now, on some otherwise-secure ciphers, this relation between the two
> keys allows for related-key attacks that compromise the cipher. For
> example: three-key triple-DES can be broken with a carefully chosen D
> (choose D so that D' flips some bits in just the third key but not in
> the first two keys).
>
> The above seems pretty far-fetched.
That would be an interesting attack, if it was successfully carried out.
> In practice, what is perhaps more worrisome is that the structure in
> the inputs might interact badly with the linearity of the CRC to cause
> some entropy to be lost. For instance, we know that XOR-ing all the
> inputs is bad, because if all the variability is in the least significant
> bit of each of N inputs, then the XOR will have only 1 bit of entropy,
> even though the concatenation of the inputs has N bits of entropy.
> Similarly, what if the feedback polynomial of the CRC causes bit positions
> in the different inputs to line up so that they cancel in a similar way?
> If the feedback polynomial were independent from the inputs, then this
> would probably not be a concern, but since the feedback polynomial is
> known and chosen ahead of time and fixed for all time, one can hardly
> make any reliable independence assumptions here.
I've considered this possibility, but I couldn't come up with a
*natural* example in which sampled randomness would interact with the
structure of a CRC polynomial. I did find a problematic scenario: a
standard CRC (e.g. CRC-32) is used to distill randomness from a random
input, which happens to be packets with some random content followed by
a CRC checksum. If the CRC's used for both applications are the same,
you would get a very predictable result: every time a packet passes
through, the computed checksum becomes 0. (In a sense, this is
artificially adding structure to the output of a source to make it
interact with the CRC. I'm not sure whether I should consider it natural
or not.)
> In any case, we know that none of this funny business can happen if
> we use a secure hash, so unless we think we understand the phenomena
> here really well, the conservative choice seems to be to just hash
> everything. No?
Agreed, but it would still be an interesting exercise to see when a
simpler solution can be used.
> Am I missing something? Maybe I've just got unjustified paranoia on
> the brain. If so, I hope you'll let me know.
I don't think you're missing something here. It's hard for someone who
chose an email address like mine to say you're being overly paranoid.
But these days I try to lower the setting of my paranoid thermostat a
little. :)
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
Date: Sun, 09 Jul 2000 11:25:10 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Concepts of STRONG encryption using variable base
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > > We all know that encryption these days are weak. Weak in the sense
> > > that they are static and can be brute force searched by permutating
> > > through the keyspace of the encyption key.
> >
> > No they cannot. Use your virtual calculator to figure out how long
> it would
> > take you to _count_ up to 2^256. Then figure out how much slower
> trial
> > decryption is compared to counting. A 256-bit key cannot be searched.
>
> This is actually a very interesting statement. Any static keylength
> can be searched through. The variable you are more concerned with
> is the time required to do it. To answer that one, I give you
> two URLs...
>
> http://www.distributed.net
> http://www.edepot.com/baseencryption.html
Don't dodge the question, just provide an answer -- using any assumptions you
want, how many years will it take?
>
>
> >
> > >
> > >
> > > One of the most revolutionary concepts of encryption that I have
> > > come up with is dynamic encryption and the use of dynamic algorithm
> > > and "keys".
> >
> > This concept is older than some written languages.
>
> Actually, if you do a patent search, here is what you will come up
> with...
>
> >
> > >
> > >
> > > Using the concepts of dynamic encryption as well as dynamic bases,
> > > one can achieve one-time-pad security without the inconveniences
> > > of using it.
> >
> > No.
>
> Yes!
Shannon provided explicit limits to cryptographic security in the concept of
unicity. If you apply that fundamental concept to your system you will find
you are wrong.
[snip gratuitous insults]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: computer program: extract consonants/vowels from input
Date: Sun, 09 Jul 2000 08:35:20 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> Darren New wrote:
> > > Whether a letter is more correctly classified as a consonant or
> > > as a vowel is, as you observe, context dependent.
> > I want to know whether the "P" in "pneumonia" is a consonant or a
> > vowel.
>
> Usually it is said to be "silent", but it's still a consonant.
As the story goes, an esteemed professor was asked why he named his do
Fido, when he could have named it something more imaginative. His reply
was to suggest looking at the name on the doghouse. There it
was...Phydeaux.
Obviously, the English Language often gives too much creative expression
to be easily condensed into a few rules, but that should be with freedom.
Stick with a short common list, AEIOU, and try not to be too worried about
exceptions getting through your filter.
--
Ralph Nader must not be a politician, he makes sense. Those that
hype confusion about understandable issues are the anarchists.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Concepts of STRONG encryption using variable base
http://www.edepot.com/phl.html
Date: 9 Jul 2000 15:24:55 +0200
In article <8k86bl$q9p$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> We all know that encryption these days are weak. Weak in the sense
> that they are static and can be brute force searched by permutating
> through the keyspace of the encyption key.
Well you *can*, of course -- if you have the time.
If you want to do a brute force search on a 128-bit key, and if
you have a very powerful computer allowing you to test 10 billion
key values per second, you would still need 3 MILLION YEARS to
search the entire keyspace.
In the future you may have a computer 1000 times faster -- but you
would then still need 3000 years to search the entire keyspace.
Futher into the future you may have a computer one million times
faster -- then you can search the keyspace in a mere 3 years. But
by then people will probably have switched to 256-bit keys, which
would require 1000000000000000000000000000000000000000 years to
search with this powerful computer of yours. This is
100000000000000000000000000000 times longer than the age of the
universe.
Do you have that much time?
--
================================================================
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: Concepts of STRONG encryption using variable base
Date: 9 Jul 2000 15:25:21 +0200
In article <[EMAIL PROTECTED]>,
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> No they cannot. Use your virtual calculator to figure out how long it would
> take you to _count_ up to 2^256. Then figure out how much slower trial
> decryption is compared to counting. A 256-bit key cannot be searched.
Well, it can, if you have enough time... :-))))
>> One of the most revolutionary concepts of encryption that I have
>> come up with is dynamic encryption and the use of dynamic algorithm
>> and "keys".
>
> This concept is older than some written languages.
Some written languages are less than 100 years old though....
--
================================================================
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: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: Sun, 09 Jul 2000 11:45:45 -0400
Bryan Olson wrote:
> So the answer yet again: there is no test that will
> always find dependence when it exists.
And there is also no test that will always find independence
when it exists. What statistical tests *do* is provide a
measure of support for or against a hypothesis; the measure
can never be certain unless the enitre population is sampled.
------------------------------
** 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
******************************
