Cryptography-Digest Digest #619, Volume #13 Sat, 3 Feb 01 04:13:01 EST
Contents:
Re: The prospects for a theoretical breakthrough in the factoring problem ("Scott
Fluhrer")
Re: CipherText patent still pending ("Michael Brown")
Re: security of cd-rw erasure? ("Michael Brown")
Re: test ("Michael Brown")
Re: Some Cryptogram deciphering help ("John A. Malley")
Secrets for Java (C. Begin)
Re: Durstenfeld Transpositions & ARC4 (Benjamin Goldberg)
Re: MIKE - alternative to SPEKE and PAK ("Michael Scott")
plumbing the depths? (Re: Breaking OAP-L3) (Matthew Montchalin)
Re: Durstenfeld Transpositions & ARC4 (Terry Ritter)
Re: On combining permutations and substitutions in encryption (John Savard)
Re: On combining permutations and substitutions in encryption (David Wagner)
Re: On combining permutations and substitutions in encryption (David Wagner)
Re: New checksum algorithm (Benjamin Goldberg)
Re: New checksum algorithm (Benjamin Goldberg)
Re: New checksum algorithm (Benjamin Goldberg)
Re: Where is the encryption hardware? (Benjamin Goldberg)
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: The prospects for a theoretical breakthrough in the factoring problem
Date: Fri, 2 Feb 2001 21:10:46 -0800
Splaat23 <[EMAIL PROTECTED]> wrote in message
news:95ft3v$81u$[EMAIL PROTECTED]...
> Doesn't the knowledge of d, e, and n give you the ability to factor n?
Correct
> If so, then any successful attack against d will give you the factors
> of n.
Wrong. Any attack that allows you to derive the value of d is equivilant to
factoring. There might be an attack that allows you to efficiently compute
e-th roots (i.e. given a, e, n, find x s.t. a = x**e mod n) without allowing
you to efficiently compute d. It is unknown whether such an attack is
equivilant to factoring.
> So, for any given n, generate a random e and try your "attack".
> If it succeeds, you factor n. If it doesn't, then e is not relatively
> prime to n, and you pick another e.
>
> Of course, if someone finds a shortcut to decryption (i.e. a formula
> that emulates the modular exponentiation without the knowledge of d)
> this factoring technique would not work.
And such a shortcut would qualify as an attack.
>
> - Andrew
>
> In article <[EMAIL PROTECTED]>,
> Roger Schlafly <[EMAIL PROTECTED]> wrote:
> > DJohn37050 wrote:
> > > For some thoughts on this, see www.cryptosavvy.com website where
> Lenstra "makes
> > > a guess" that improvements in factoring will continue as they have
> been in the
> > > past. Also, I think an RSA Cryptobytes discussed this, but do not
> remember
> > > which one.
> >
> > There is also the possibility that someone will find an RSA attack
> > that does not involve factoring.
> >
> > > If you are REALLY worried about an algorithm breaking, you could
> use 2
> > > algorithms, say ECC and RSA. Breaking both at the same time would
> be quite a
> > > stunt as the known best methods to break them are very different.
> DSA does not
> > > work for this as it breaks if EITHER RSA (GNFS) or ECC (Pollard
> Rho) methods of
> > > attack are improved.
> >
> > An RSA break may not endanger DSA because
> >
> > 1. the RSA break may not even use factoring.
> > 2. a factoring breakthru may not help with discrete logs (as was
> > the case with the elliptic curve factoring method).
> > 3. even an improvement to GNFS may not help with DSA too much.
> > (GNFS broke 512-bit RSA but not 512-bit DSA).
> >
> > Also an ECC break may not endanger DSA. Of the various ECC
> > weaknesses found so far (supersingular curves, trace 0 curves, etc),
> > none have affected DSA.
> >
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Sat, 3 Feb 2001 18:50:28 +1300
I wonder if there should be a sci.crypt.newciphers? NG for posting your
ciphers without having to get it all mixed up with all the other crypto
stuff. Also be a good practice ground for cryptanalys.
It'd have to have various rules such as
1) Only 1 post per cipher (or revision) of the form "<cipher name> -
<version>" or something - we'd get a nice tree structur then :)
2) No overkill. It's worse to see your cipher get totally blasted to bits
rather than just busted.
And some others that would probably develop.
Just an idea.
Michael
"Richard Heathfield" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Bryan Olson wrote:
> >
> <snip>
> >
> > Good as those questions are, when I read yet another report
> > of the development of a new symmetic cipher, the first
> > question I ponder is not one those, or others listed in the
> > FAQ.
> >
> > Is is: Why?
> >
> > Does it solve some problem that other ciphers don't? Can
> > they prove something interesting about this cipher that is
> > not true of others? Is there some reason anyone should care?
> >
> > Are people so mis-informed as to think that a symmetric cipher
> > for which no one produces an effective attack is an interesting
> > or novel result? Or that there might be commercial potential
> > for one? Or that a good learning exercise for a student is to
> > design a cipher?
>
> None of the above.
>
> We do it because it's fun.
>
> Of course, that doesn't mean that it's fun for everyone else on
> sci.crypt to read about it. Some of us learn that, eventually. We know
> we're not going to write a competitor to Rijndael (all right, AES) or
> Twofish, but that doesn't matter. The idea of making an omelette out of
> our bits, and then turning that omelette back into an egg /only if/ the
> right magic words are uttered, is intrinsically fascinating. Once we've
> done that, it's only natural (if a little child-like) to want to show
> other people - "Look what I did! Isn't it /cooool/?" And who do we want
> to show our achievement to? Well, obviously it should be to people
> who'll understand it. Equally obviously, that means sci.crypt. (Yes, the
> FAQs, but sometimes we're a bit too excited to remember to read them.)
>
> In the midst of our natural joy of discovery, we tend to forget that
> sci.crypt understands what we have achieved only too well. I first
> posted my "CDX" algorithm here over a year ago (if I recall correctly).
> It was torn into tiny little pieces (quite gently, to be fair) by a
> couple of people. Since then, I've toyed with it occasionally, fixed
> some stuff, added some stuff... it's a lot quicker than it was, and a
> lot more secure than before. But I no longer ask people here to
> cryptanalyse it. That's too dispiriting. If truth be told, you see, I
> don't really want anyone to break it. I just want to pretend it's
> unbreakable. I don't pretend that to anyone else, of course. The only
> customer I have in mind for my snake oil is - me.
>
> My symmetric cipher was a lot of fun to write. It was less fun to fix
> after sci.crypt thumped it. It'll be still less fun to fix next time
> round, which is why there won't be a next time round. If I went that
> route, by the time I'd fixed every problem sci.crypt found with the
> algorithm, it would end up looking just like everyone else's algorithm.
> And where's the fun in that?
>
>
> --
> Richard Heathfield
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Crossposted-To: alt.comp.periphs.cdr
Subject: Re: security of cd-rw erasure?
Date: Sat, 3 Feb 2001 19:05:32 +1300
> For both CDR's and CDRW's, it appears that if you really want your
previous
> use inaccessible, it is best to heat the CD to a molten state so that it
> ends up looking like a Salvadore Dali watch.
There were _many_ threads on this a while ago. Search Deja for "cd
destruction" in the sci.crypt newsgroup. Many of them were quite
interesting.
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: test
Date: Sat, 3 Feb 2001 19:06:56 +1300
> A "eraze message" command exists ;-)
How do you do this? There's been _many_ times I've screwed up a message ...
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Some Cryptogram deciphering help
Date: Fri, 02 Feb 2001 22:24:13 -0800
Maybe a xenocrypt?
The original post said it was a quote. There are many famous quotes in
Latin. The "guuy" pattern reminded me of Latin - but it's just a hunch.
I found tables of Latin alphabet character frequencies, and frequencies
for digraphs, trigraphs and common small Latin words in Lesson 6 of
LANAKI's on-line course. So far though I've not made headway looking for
a simple substitution cipher on Latin plaintext.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: C. Begin <[EMAIL PROTECTED]>
Subject: Secrets for Java
Date: Sat, 03 Feb 2001 06:20:18 GMT
http://www.ibatis.com
Look for the Secrets link. No tricks, no BS. Source code available.
It does what it does. Tell me what you think. Works much like PGP,
written in Java and based on the Java Cryptography Architecture.
Regards,
Clinton Begin
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Sat, 03 Feb 2001 06:55:01 GMT
Terry Ritter wrote:
>
> On Fri, 02 Feb 2001 09:17:29 GMT, in
> <[EMAIL PROTECTED]>, in sci.crypt Benjamin Goldberg
> <[EMAIL PROTECTED]> wrote:
>
> >Terry Ritter wrote:
> >>
> >> On Thu, 25 Jan 2001 19:57:58 -0800, in
> >> <94qsjr$qfk$[EMAIL PROTECTED]>, in sci.crypt "r.e.s."
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >[snip]
> >> >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
> >>
> >> The ARC4 state is awfully small for Dynamic Transposition,
> >> especially if we shuffle twice. We want more active state in the
> >> RNG than is used in a single encryption, and probably do want at
> >> least 128 bits in the block. Since rejection in Shuffle (to
> >> achieve variable-range) throws away values (and may throw away a
> >> lot), probably it is not large enough.
> >
> >The purpose of having a particular size state PRNG is to allow every
> >possible permutation to be a possible result of our PRPG (psuedo
> >random permutation generator). No significant change is made to the
> >size of the range of possible permutations by double shuffling, so
> >there's no reason to require a larger PRNG state if double shuffling
> >is used.
>
> Well, here it is from the original article:
>
> "If we shuffle each block just once, an opponent who somehow
> knows the correct resulting permutation can use that
> information to reproduce the shuffling RNG sequence, and
> thus start to attack the RNG." "This does not
> produce more permutations, it just hides shuffling sequence."
>
> Now, since that was insufficient, let me try it again:
>
> "The" purpose of having a lot of state in the RNG is to allow every
> possible *pair* of two permutations.
>
> Essentially, Shuffle is reversible. With only one shuffling, if the
> opponents get the permutation, they immediately have a pretty good
> idea what sequence produced that permutation. (The information would
> be inexact, but far, far better than nothing.) With two independent
> shufflings, there is no such implication.
>
> If there is only enough state in the RNG for a single shuffling, any
> second shuffling will be correlated to the first by way of the limited
> RNG state, and, thus, not independent. So knowing the final
> permutation might allow the development of the double-length shuffling
> sequence which produced the known permutation. That has not helped.
>
> The purpose of having enough information for *two* *independent*
> shufflings is to isolate the sequence generator from the permutation.
> Two shufflings use twice as much information (sequence) as needed to
> form a permutation, so two shufflings use twice as much information as
> the resulting permutation can represent. Even if the opponents do get
> the final permutation, the uncertainty in the sequence used to build
> that permutation will be as though we had a non-reversible shuffle.
Aaah, now I get it.
Now I've a silly question: With the double-shuffling method, is it
possible for us to [safely] use as our PRNG a simple LFSR, with nothing
fancy added to obscure the state (like shrinking, variable clocking,
etc)?
Assuming it's large enough state, that is. Also, would it still be
secure if the LFSR polynomial is sparse (eg, a trinomail)?
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: MIKE - alternative to SPEKE and PAK
Date: Sat, 03 Feb 2001 06:55:21 GMT
"Michael Scott" <[EMAIL PROTECTED]> wrote in message
news:iWLe6.100186$[EMAIL PROTECTED]...
>
> "Thomas Wu" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > "Michael Scott" <[EMAIL PROTECTED]> writes:
>
> Thanks to Tom, David and Phil for thier encouragement. I haven't given up
> yet....
> Hmmm. I think Carol needs to check that Steve has been behaving himself...
I
> think there are a number of ways of doing this.
> Its also not clear to me that r and b need to be distinct, so
>
> 3. Carol: A=3^a mod p
> 4. Steve: B=(3v)^b mod p, u=4^b, w=H(12^b). Sends {B,u,w} to Carol.
> 5. Carol checks that H(Bu/u^x) =?=w, otherwise aborts. Then Carol
calculates
> S=(B/u^x)^a. Steve calculates S=A^b.
>
Or, since I have an irrational dislike of hash functions, a,c,b,r random.
3. Carol: A=3^a mod p, w=4^c mod p. Sends {A,w} to Steve
4. Steve: B=3^b.v^r mod p, u=4^r (El Gamal encryption of 3^b), Sends {B,u}
to Carol.
5. Carol: S=(B/u^x)^a.u^c mod p. Steve calculates S=A^b.w^r mod p
The idea is to force u to be 4^something by integrating a base-4
Diffie-Hellman into the protocol.
Mike Scott
>
>
> > Tom
> >
> > > --
> > > > Tom Wu * finger -l [EMAIL PROTECTED] for
> PGP
> > > key *
> > > > E-mail: [EMAIL PROTECTED] "Those who would give up their
> freedoms
> > > in
> > > > Phone: (650) 723-1565 exchange for security deserve
> > > neither."
> > > > http://www-cs-students.stanford.edu/~tjw/
> > > http://srp.stanford.edu/srp/
> > >
> > >
> >
> > --
> > Tom Wu * finger -l [EMAIL PROTECTED] for PGP
> key *
> > E-mail: [EMAIL PROTECTED] "Those who would give up their
freedoms
> in
> > Phone: (650) 723-1565 exchange for security deserve
> neither."
> > http://www-cs-students.stanford.edu/~tjw/
> http://srp.stanford.edu/srp/
>
>
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,sci.crypt.random-numbers
Subject: plumbing the depths? (Re: Breaking OAP-L3)
Date: Fri, 2 Feb 2001 23:48:15 -0800
On Fri, 2 Feb 2001, Richard Heathfield wrote:
|Let me give you an example of how easy it is to Do The Right Thing.
|I, too, have designed a cryptographic algorithm. I make no great
|claims for it. But I do know how to describe it simply. I'll show
|you. (This is from memory. I might have got the details slightly
|wrong. Irrelevant.)
|
|CDX-2 is a block cipher, where the blocksize is equal to the filesize.
|:-)
|
|for i = 1 to keysize
|{
| for j = 1 to plaintextsize
| {
| C[j] = S_Box[P[j]]
| }
| rotate entire block by LUT[K[i]] bits
| for j = 1 to plaintextsize
| {
| C[j] = C[j] ^ K[j % keysize]
| }
|}
|
|(LUT == LookUp Table)
|
|THAT'S IT. That's all there is to it.
|
|And if people don't understand my description, I will consider it my
|failing, not theirs, and I will publish a clarification.
Okay, what a cute little pseudo-algorithm.
How well does it pass the tests for randomness?
How would you go about attacking it for randomness?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Sat, 03 Feb 2001 08:04:29 GMT
n Sat, 03 Feb 2001 06:55:01 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>[...]
>Now I've a silly question: With the double-shuffling method, is it
>possible for us to [safely] use as our PRNG a simple LFSR, with nothing
>fancy added to obscure the state (like shrinking, variable clocking,
>etc)?
That is a cryptographic design issue: tradeoffs must be made in the
context of a lack of information. Were there a literature of cipher
design, such that the strengths of various mechanisms was known, as
used in various ways, we could just pick and choose. Everybody would
agree. Nobody would guess. But there is no cipher design handbook.
Personally, I try to have multiple levels of strength in a cipher.
That is, I try to use different mechanisms which each seem strong in
different ways, so that if one fails (that is, if I am mistaken about
the strength), there is a backup, and a backup to that.
>Assuming it's large enough state, that is. Also, would it still be
>secure if the LFSR polynomial is sparse (eg, a trinomail)?
Again, it is a design issue. The answer depends upon context, and
what one can imagine what an opponent might be able to do.
There is some evidence that relatively small trinomials produce
sequences that are "less random" than one might like, but that issue
does not extend to what I think of as cryptographic sizes. It might
even be argued that sometimes what we really want is a large distance
between terms, which of course would imply trinomials.
On the other hand, if poly choice is part of keying, it probably makes
sense to use 9-nomials. But then you have to find them.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: On combining permutations and substitutions in encryption
Date: Sat, 03 Feb 2001 01:12:48 GMT
On Fri, 02 Feb 2001 23:45:27 GMT, Bryan Olson <[EMAIL PROTECTED]>
wrote, in part:
>I didn't read all the posts on the subject - is there a
>defined minimum block size for DT? The amount of output loss
>from the generator varies with the block size. At the
>smallest possible size, one bit of plaintext per block, a
>known plaintext attack would get the PRNG output directly.
No, but it was envisaged to be used with block sizes of 4,096 bits and
up or something in that area.
In any case, the loss of the generator output is never _total_; for a
given input block and output block of length N, there are always
(N/2)!(N/2)! permutations out of N! which may produce that
encipherment.
Thus, one has *partial* information about the permutation, and from
block to block, one can combine that information.
Compared to something that uses, say, two layers of XOR and a fixed
substitution table in the middle, or, say, two or four rounds of DES
with stream-cipher generated subkeys, maybe combining the partial
information might be more difficult - this would depend on the precise
nature of the pseudo-random permutation generator used.
I think the cipher is interesting simply because I haven't seen too
many designs that combine a stream cipher which changes how every part
of the text is enciphered with a block cipher that makes the
encipherment less trivial than an XOR of a PRNG output. Long after
Terry Ritter came up with DT originally, I proposed - but not too
seriously, as I realized it was too big and elaborate - the "Large-Key
Brainstorm" which is such a design.
DT is more practical, by providing this kind of design with more
reasonable complexity.
This basic design has the obvious advantage that the attacker has to,
at the same time, somehow both mount an attack against the combiner
using techniques like differential cryptanalysis, and predict the
output of the PRNG. Obviously, that can be much more difficult than
trying to solve a cipher with only one of the two components.
While this doubtless would make ciphers more secure, I don't think
it's possible to say with any confidence that it brings us any closer
to a *mathematical proof* of security. I haven't been convinced by
what appeared to be his arguments for that.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: On combining permutations and substitutions in encryption
Date: 3 Feb 2001 08:16:58 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Terry Ritter wrote:
>Allow me to draw attention to the fact that this discussion -- or at
>least the part concerning me, and I *was* the first response in this
>thread -- is about *practical*, not theoretical security.
Fine. But it's also about *provable* security.
If you build any cipher that (1) runs in polynomial time,
and (2) you can prove breaking it requires super-polynomial
time, then you've solved the P != NP question.
If you have a proof that "DT" satisfies (1) and (2), we'd be
very interested to hear. In the absence of such a proof, I think
the fact above makes it unlikely that it will be easy to find such
a proof.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: On combining permutations and substitutions in encryption
Date: 3 Feb 2001 08:21:28 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Terry Ritter wrote:
>I "claim" that it obviously is possible to provably defeat particular
>attacks in practice. I offer as evidence brute force attacks on keys
>and their defeat by using larger keys.
Ahh, well, that's well and good, but it's not a proof that
the Don Coppersmiths of the world can't find some other attack.
We can find plenty of ciphers where we can *prove* that
exhaustive keysearch doesn't work. Anyone can build a cipher
that resists exhaustive keysearch; that's trivial. Even FEAL
had this property!
Note that we also have plenty of ciphers where we can *prove*
that certain other classes of attacks don't work -- for instance,
certain types of differential cryptanalytic attacks. So it's not
clear to me what's new about "DT", from a provable security point
of view.
Bottom line. The problem with all of these ciphers is that
there's no proof that some other, clever-er attack technique
won't break them. We don't know how to build a provably secure
cipher.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Sat, 03 Feb 2001 08:25:46 GMT
Joseph Ashwood wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Dumb question: What are the general criteria for
> > evaluating methods of obtaining checksums? Thanks.
> It's not a dumb question. The criteria are to not be able to find two
> input x, x' where x != x' where hash(x)=hash(x'). That is the outer
> appearance, just as with encryption algorithms, there is also the
> matter of whethere or not successfully cryptanalyzing a sub-portion of
> the algorithm is considered a break. And of course whether or not even
> the attacker is allowed to choose x and x' or if they are given x.
This is true of cryptographic hashes, but the question was about
checksums. Generally, one wants a checksum to be able to detect random
changes to the message with high probability. It's requirements seem
similar to what of a hash, but with a checksum the assumption that there
is no hostile attacker -- changes are assumed to be caused by the
transmission medium, or bitrot, or cosmic rays, or whatever, and the
information in the checksum should, in some cases, be enough to correct
them.
> In general though the rules depend on the algorithm, for example is
> someone were to find a successful linear attack against against a
> linear layer of Whirlpool, no one would care, however when someone
> found an attack against the compression function of MD5 careful note
> was taken.
> Joe
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Sat, 03 Feb 2001 08:29:50 GMT
Robert Scott wrote:
[snip]
> For serial communications over a noisy line, for example,
> permutations of input items is not particularly likely. In fact,
> I can't think of any naturally-occurring setting (other than
> intelligent tampering) where permutation of items is likely.
Suppose we are sent information in numbered packets, and the LSB of the
packet number in both two adjacent packets gets flipped. Our packet
assembler would produce a stream with the contents of the packets in the
reverse order.
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Sat, 03 Feb 2001 08:31:43 GMT
Terry Ritter wrote:
>
> On Fri, 02 Feb 2001 22:13:58 +0100, in
> <[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >I like to take this opportunity to ask a question of ignorance:
> >Why does e.g. CRC-16 use a polynomial of degree 16? (I had
> >expected one of degree 15, since that can be represented with
> >16 bits, while one of degree 16 can't.) Thanks in advance.
>
> The remainder from a degree 16 poly is a degree 15 poly, and a mod 2
> deg 15 poly has 16 bits: 15, 14, ... 1, 0.
Plus, since the x^16 coefficient is always 1, it never needs to be
stored in the variable holding the taps.
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Where is the encryption hardware?
Date: Sat, 03 Feb 2001 09:01:51 GMT
Steve Portly wrote:
[snip]
> As you noted synching a new user utilizing a "strong" public key
> method can take several minutes with the weaker processors used in
> cell phones.
> Changing to a channel hopping standard such as CDMA would deter
> "scanner monkeys" using commercially available scanners from
> acquiring signal.
> Passing the symmetric key in the open or lightly encrypted using an
> appropriate key subset might improve security even more.
Right. Any of these things will provide security against amatures. The
problem, however, is that none of them are done, even though it would be
easy to do.
> A determined cracker who has you targeted and is recording the entire
> cell phone transmission could likely crack any "convenient" cell phone
> synch however.
True enough, but how often do we have someone targetting us? I'm just
worried about nosy neighbors.
Also, I can think of one kind of convenient remote phone key sync which
can't be cracked easily, though it's not for cell phones. If you have a
cordless phone (the type with a fixed base, installed in your house),
simply re-key through a physical connection each time you hang up to
recharge. True, this does do anything about wiretaps, but again, it
does prevent amatuers from listening in with a scanner.
Also, here's another idea... suppose secure key exchange takes 5
seconds. Most of that is calculation, not transmission. It would not
be too hard to start the exchange when the connection is made, and allow
unencrypted conversation start immediatly, do the computations in the
background, and switch to encrypted conversation as soon as the key
exchange completes.
Done this way, even a secure connection can be completely 100%
transparent to the user, with the minor drawback that the first few
seconds of the connection are unencryped. How often important are those
first few seconds? "Hi, Joe, how are you doing, how's the weather..."
AFAIK, current systems which use secure key exchange don't allow any
conversation until the exchange completes. Since people prefer to start
talking as soon as they're connected, they generally don't use these
systems.
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
