Cryptography-Digest Digest #100, Volume #12 Sat, 24 Jun 00 14:13:00 EDT
Contents:
Re: Simple Key Escrow ("Adam Durana")
Re: Simple Key Escrow (tomstd)
Re: How Close? (Scott Nelson)
Re: Linear Feedback Shift Register *with* lock-up? ("CrakMan")
Re: Try it. ("Trevor L. Jackson, III")
Re: Compression & Encryption in FISHYLAND ("Trevor L. Jackson, III")
Re: Simple Key Escrow ("Adam Durana")
Re: Algo's with no easy attacks? ([EMAIL PROTECTED])
Quantum computing ([EMAIL PROTECTED])
Re: Algo's with no easy attacks? (tomstd)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Algo's with no easy attacks? (Simon Johnson)
Re: Quantum computing (David A Molnar)
Re: Tiny hash? (Rex Stewart)
Re: how to compare the securtity between ECC and RSA (Roger Schlafly)
----------------------------------------------------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Simple Key Escrow
Date: Sat, 24 Jun 2000 11:08:10 -0400
How about...
K = Master 128bit key held by law enforcement
S = 128bit serial number for a crypto device
K2 = Secret key only put on crypto device which is S encrypted using K.
R = 128bit random number
K3 = R encrypted using K2
So for any message you want to send you'd generate a R, which would then be
encrypted by K2 to yield K3. Then you use K3 to encrypt your message and
you append S and R to your ciphertext and send it. So an attacker would
have to figure out what key was used to encrypt R to yield K3. Once they
had that key, which is K2, they could then work on finding the key which
encrypts S to yield K2. If they figure that out, then they have K and
everyone is screwed! Big brother would only have to take S, encrypt it
using K, to get K2, then encrypt R using K2 to get K3 and then be able to
read the ciphertext.
- Adam
"tomstd" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> This has probably been thought of, just want some insight!
>
> What about a system where the law agency (LA) has a master 128-
> bit key (and we are using 128-bit block ciphers) K. Now all
> chips that have crypto have 128-bit serial numbers R on them.
> Each chip has an embeded 128-bit key K2 that is derived from Ek
> (R) so that only the chip and LAW know K2.
>
> Now when I want to send a message I make up a key like I
> normally would then encrypt it with my K2 and send my
> ciphertext, the K2 encrypted key and my serial number.
>
> In total 256-bits is added to the message. Nobody can tell the
> K2 from the serial numner (easily) and nobody can tell K from a
> K2 and serial number easily...
>
> Just some ideas...
>
>
> Tom
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
>
------------------------------
Subject: Re: Simple Key Escrow
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 24 Jun 2000 08:34:05 -0700
"Adam Durana" <[EMAIL PROTECTED]> wrote:
>
>How about...
>
>K = Master 128bit key held by law enforcement
>S = 128bit serial number for a crypto device
>K2 = Secret key only put on crypto device which is S encrypted
using K.
>R = 128bit random number
>K3 = R encrypted using K2
>
>So for any message you want to send you'd generate a R, which
would then be
>encrypted by K2 to yield K3. Then you use K3 to encrypt your
message and
>you append S and R to your ciphertext and send it. So an
attacker would
>have to figure out what key was used to encrypt R to yield K3.
Once they
>had that key, which is K2, they could then work on finding the
key which
>encrypts S to yield K2. If they figure that out, then they
have K and
>everyone is screwed! Big brother would only have to take S,
encrypt it
>using K, to get K2, then encrypt R using K2 to get K3 and then
be able to
>read the ciphertext.
I think you just described what I original thought of two
seconds ago.
I just neglected the message key for obvious reasons.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: How Close?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 24 Jun 2000 16:10:13 GMT
On Sat, 24 Jun 2000 Future Beacon <[EMAIL PROTECTED]> wrote:
>
>
>How random do you think these numbers are:
>
>Large files of equal size A, B, and C are composed of the
>least significant two bits of bytes found in news group messages
>(excluding headers, carriage returns, line feeds, and spaces).
>In each case, these bits are strung together, four pairs per byte
>in these files. At least three quarters of the original data is
>not used. Let's assume that the files are over a megabyte in size.
>
A quick check shows a significant bias in favor of 01, and against 11.
If we pretend that the bits are independent, then there's a bias
toward 1.
>Then, file B is divided into two files (BP and BQ) this way: If the
>first bit in A is a 0, then the first bit in B becomes the first bit
>in BP. If the first bit in A is a 1, the first bit in B becomes the
>first bit in BQ. Each next bit in A determines whether the next bit
>in B becomes the next bit in BP or BQ. When the bits of A and B are
>exhausted, BQ is appended to BP and the resultant file is called RAND.
>
>How random is RAND?
>
That procedure will not change the ratio of 1's to 0's.
The resultant file will still be biased.
It may also introduce new correlations, but it probably
doesn't make it any worse than it was originally.
There was little point in creating the file C,
since it's not used in the procedure.
This suggests that the procedure as outlined was not
what you intended. I recommend re-reading your post,
then re-writing it, and then submitting it to
the more appropriate sci.crypt.random-numbers
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "CrakMan" <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math
Subject: Re: Linear Feedback Shift Register *with* lock-up?
Date: Sat, 24 Jun 2000 09:13:42 -0700
Hook up an EPROM and an N - bit latch as a simple state machine. The
outputs of the latch go to the address inputs of the EPROM. The outputs of
the EPROM are connected to the latch inputs.
You fill the EPROM with code which will cause the state machine to do your
sequence until the magic last value is achieved. The next value then runs
in a closed loop and never changes until reset.
You can easily write a little C routine to fill the EPROM.
Two parts, a few wires. Build it in a half hour...Yawn, next question :--)
John E. Kuslich http://www.crak.com Password Recovery Software
Ponder <[EMAIL PROTECTED]> wrote in message
news:8iocit$1ghu$[EMAIL PROTECTED]...
> I'm looking to use a Linear Feedback Shift Register to implement
> a counter with minimal resources (i.e. fewer gates and wires than
> an additive incrementor). I've seen quite a bit of cryptographic
> literature on how to use an N-bit LFSR to count through (2^N)-1
> values before repeating. There is one value (usually all 0's or
> all 1's) where the LFSR would be "stuck" at the same value as
> it counts.
>
> What I'm really looking for, though, is an LFSR that counts
> through 2^N values and then *does* get stuck in the last state.
> This way when I find it stuck, I would know that it counted through
> all the values since its initial state. There would be one
> "minimal" value for the initial state, that would cause it to
> count through all 2^N values before sticking; if I want to count
> fewer steps I would pick an initial value further along the
> sequence.
>
> Does anyone out there know how to do this? I've looked at some
> of the polynomial theory on LFSR's, but guess that it only
> applies to counters that actually loop through a sequence rather
> than iterating through a sequence and looping on a final value.
>
> Also, is there a good algorithm for converting the elements of
> an LFSR sequence into the actual value of the count? (Or more
> precisely, for mesuring the number of iterations between two
> values). For small N you could just count through the sequence
> until you find a match, but I'm interested in N around 32 or 64
> so this would take too long.
>
> Thanks in advance,
>
> Carl Ponder
> [EMAIL PROTECTED]
>
> --
>
> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
> Carl Ponder, Ph.D. Carl Ponder [EMAIL PROTECTED]
> AIX Performance Tools IBM Server Division Phone: (512) 838-1638
------------------------------
Date: Sat, 24 Jun 2000 12:33:49 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Try it.
Boris Kazak wrote:
> "Trevor L. Jackson, III" wrote:
> >
> > "Trevor L. Jackson, III" wrote:
> >
> > >
> > > Le plus ce change, le plus c'est le meme chose.
> > >
> >
> > It has been pointed out to me that I no longer speak French in any meaningful
> > way. Apologies to any offended fracophiles.
> --------------------------------------
> I have a suspicion that the redneck who pointed this out to you
> declares himself as a devout Christian. (This idea could not have
> occurred to an atheist, I know this, I am one myself).
Moi aussi, but I''ll admit to being lapsed.
>
> And, BTW, John-Paul II in Rome speaks 15 languages, French and
> English included. This "Christian" who reprimanded you for using
> French, is in fact refusing to follow the example set forth by his
> own pontiff... Sic!
>
> "Paris, ca vaut la messe!!"
> ����� ����� ������!!
> Paris is worth a cermon!!
>
> Best wishes BNK
------------------------------
Date: Sat, 24 Jun 2000 12:40:18 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Statements that start "You are ..." are a distinguishing characteristic of
messages not worth reading. Simpler to #include <stdinsult>.
zapzing wrote:
> I have a wonderful idea! Let's just compress
> all messages of the form "you are a
> presumptuous bastard" and/or "you are an
> ignorant foolish jerk" etc. to the small
> case letter z!
>
> --
> If you know about a retail source of
> inexpensive DES chips, please let
> me know, thanks.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Simple Key Escrow
Date: Sat, 24 Jun 2000 12:29:03 -0400
> I think you just described what I original thought of two
> seconds ago.
>
> I just neglected the message key for obvious reasons.
Your system has a message key, the one that is encrypted with K2 and
attached to the ciphertext. Or do you mean something different? Lets call
the message key K3, and call K3 encrypted using K2, eK3. eK3 is appended to
the ciphertext. So all I have to do to recover K2 and K3 at the same time
is keep decrypting eK3 and using the output of that to decrypt the
ciphertext until I get my known plaintext. Once I find the right key which
decrypts eK3 to get the key that properly decrypts the ciphertext, I will
have K2 and K3. Since eK3 is just K3 encrypted using K2. Also once an
attacker recovers K2 he or she will be able to recover all future K3's from
the eK3's which are appended to the messages you send.
The same sort of problem exists in what I posted...
K = Master 128bit key held by law enforcement
S = 128bit serial number for a crypto device
K2 = Secret key only put on crypto device which is S encrypted using K.
R = 128bit random number
K3 = R encrypted using K2
K3 is the message key, and R and S are appended to the ciphertext before it
is sent. An attacker would just have to kept encrypting R, until he or she
found the key that correctly decrypts the ciphertext. Also now that the
attacker has K2 he or she can simply encrypt the R in any message I send to
get the K3 for that message and be able to read the plaintext.
Another way you could do my method would be using a hash function...
K = Master 128bit key held by law enforcement
S = 128bit serial number for a crypto device
K2 = Secret key only put on crypto device which is HASH(S || K).
R = 128bit random number
K3 = HASH(R || K2)
But the same problems exist. There is one huge problem with both of these
systems... you have to trust the law enforcement to keep K safe. And once K
is discovered the whole system is no longer secure.
An attacker could work on finding K even without deliberately recovering K3
and K2. An attacker would just have to find a K such that a cipher text
decrypted with E(R, E(S,K) ) to the right plaintext. And with your method
the attacker would have to find a K such that the ciphertext decrypted with
D(eK3, E(S,K)) to the correct plaintext. And with my method using a hash
function an attacker would just have to find a K such that the ciphertext
decrypted with HASH( R || HASH(S || K) ) to the right plaintext. So I don't
think any of these systems do a very good job of protecting K from an
attacker.
- Adam
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Algo's with no easy attacks?
Date: Sat, 24 Jun 2000 10:05:25 -0700
How about the ciphers that combine several publicly known real random
sequences?
Joseph Poe
Simon Johnson wrote:
> Yup,
>
> Most ciphers have no *easy* attacks, but they can usally be
> attacked in some way, shape or form.
>
> The real question is your definition of easy, is a requirement
> of 2^62 known plain-texts an easy attack?
>
> Really, i can only invisige that the One Time Pad is the only
> attack-less cipher out there.
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Quantum computing
Date: Sat, 24 Jun 2000 10:06:51 -0700
What will come first a quantum computer or a proof that P != NP? Does
anyone want to bet?
J. Poe
------------------------------
Subject: Re: Algo's with no easy attacks?
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 24 Jun 2000 09:56:44 -0700
[EMAIL PROTECTED] wrote:
>How about the ciphers that combine several publicly known real
random
>sequences?
How random could a publicly known sequence be?
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Sat, 24 Jun 2000 19:26:42 +0200
Mark Wooding wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > So from which sentence of mine did you conclude that I was suggesting
> > to other people to 'fiddle about loads of different modes'? That there
> > ARE a number of modes is indeed what I called attention to, but where
> > is the suggestion of 'fiddling'?
>
> There are indeed many chaining modes. I don't believe that I ever
> denied this. By `fiddling', I was referring to the idea of choosing
> from among a suite of these in order to add a few more effective key
> bits.
O.k. (I protested because I understood that the word 'fiddling'
contains a negative meaning from the outset.) Now, as I repeatedly
explained, for any reader who is in the lucky situation of being able
to obtain arbitrary high strength encryption algorithms, my original
post is of NO value. (I couldn't though prevent wasting his time on
his first pass reading through my post). So, if you want to discuss
on the present topic, you have naturally to accept that the context
of discussion is that it is assumed that the best algorithm that one
can obtain is not strong enough and consequently one needs
improvements equivalent to (indirectly) increasing the key size
by some means. If you happen to know of some better means of
achieving that goal, then please kindly name these (and I suggest
that you can possibly better create a new thread to discuss them).
Otherwise, we unfortunately have to be contented with considering
chaining modes, which happen however to be able to offer only a
tiny few additional key bits.
> > Your favorite mode is CBC. There can no objection from others against
> > your having that opinion at all. But you are clearly opposing my
> > making publicity for the 'exsistence' of the other candidate modes,
> > aren't you?
>
> Nope. Definitely not. I'm opposing the idea of using the choice of
> mode as a secret.
O.k. We could discuss on that. Please give your arguments. (Note that
this issue is independent of the issue of whether chaining only adds
a couple of bits to the key space.)
> > There could be many reasons why a particular algorithm has to be used
> > and there is no other choice. For instance, it could be that my boss
> > is strongly of the opinion that 3DES should be used, because it is a
> > current standard,
>
> Do you have a problem with the security offered by triple-DES which
> adding 4 more bits of key would help? I certainly don't.
I could for argumentation's purpose just as well have given an entirely
hypothetical example. So your questioning about 3DES is not relevant
in the PRESENT context, right? (I could have instead given an example
like this: My boss, who happens to be a friend of an amateur crypto
designer, insists on using and buying the software developed by the latter,
the security of which I am however not very sure. Do you find this version
of an example better for you?)
> > or it could be that my firm has already invested much money in certain
> > hardware and is unwilling to throw these away and buy new ones. That
> > leaves me not much room to manoeuvre than trying to see whether I
> > could improve the matter a bit through using some chaining modes which
> > in my personal judgement are better than ECB.
>
> Almost any chaining mode is better than ECB.
Right. Then we could discuss CBC AND the other 7 varaints, couldn't
we?
> > But something better IS anyway better than without that something,
> > isn't it?
>
> No. Bad cryptography is worse than no cryptography at all, to someone
> who can't tell the difference, because it is given trust.
We are using chaning so to say on top of a given encryption algorithm.
So, what does your 'bad cryptography' mean in the present context?
Do you mean the algorithm you have at hand is bad? I suppose this
is not what you mean. The only interpretation that remains of your
sentence above is then that chaining itself is bad cryptography. In this
case I would like to refer you to Schneier's AC.
> > Why should one close one's eyes and forego a chance simply because
> > that chance is not very attractively big?
>
> I'm not suggesting doing anything blindly. I'm suggesting choosing a
> cipher to do the job of a cipher, which is to encrypt data strongly, and
> a chaining mode to do the job of a chaining mode, which is to hide the
> block structure of a block cipher.
Did I EVER suggest 'doing chaining blindly' in my original post? If yes,
please quote me. If not, then your second sentence is quite evident and
I have no objection to that as a general principle. If you claim that in
your opinion only one single sepecific chaining mode can be used
because the others are all inferior, then I would say that we should
discuss on that point.
> > That's EXACTLY why one should keep ones eyes open to ALL opportunities
> > of improving one's security that one can afford to exploit.
>
> No! I think that we should do enough that we believe that compromising
> our secrets is well beyond our conservative estimate of the adversary's
> capabilities. If we can't do that, we're probably better off by not
> deluding ourselves by doing a half-good job. Half-good security isn't
> better than none -- it's worse.
O.k. Suppose that the best cipher you could manage to get is not
good enough, but almost. Suppose adding the strength due to chaining
renders it above the capability of the opponent. Would you care to use
chaining in this situation or not?
> By the way, I suspect that I can identify most simple chaining modes
> using some extremely simple chosen plaintext queries.
The purpose of my original post is to elicit more discussions on chaining.
I should therefore appreciate your presenting your techniques. It doesn't
matter if these are not yet fully developed ideas. We could discuss
nonetheless.
M. K. Shen
------------------------------
Subject: Re: Algo's with no easy attacks?
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sat, 24 Jun 2000 10:21:06 -0700
[EMAIL PROTECTED] wrote:
>How about the ciphers that combine several publicly known real
random
>sequences?
>
Hmmm, if your trying to use this in the OTP sense, then the
resultant cipher is weak.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Quantum computing
Date: 24 Jun 2000 17:24:15 GMT
[EMAIL PROTECTED] wrote:
> What will come first a quantum computer or a proof that P != NP? Does
> anyone want to bet?
Quantum computers are here now. Do you really mean "a quantum computer
which can factor an RSA modulus used in practice" ?
-dmolnar
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: Tiny hash?
Date: Sat, 24 Jun 2000 17:38:05 GMT
Maybe he mis-stated his needs.
Perhaps what he really needs is a keyed CRC. If his opponet is
a mindless virus, or non crypto educated hacker, and he keeps
both the CRC and Key off line he might think 8 bits is enough.
(I disagree, but He might think that.)
In this case, what he probably needs to find is a good
ASM programmer who can fiddle with the old CRC-16 routine
to create a keyed version. (I still think he would need at
least 32 bits, and in most cases 32 bits would actually be
faster - but that is my opinion.)
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
In article <[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> None exist because an 8-bit output is useless.....
> Using the Birthday attack you need to search just 2^4 = 16
> text's to find a collison.
>
> Like i said, useless
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: how to compare the securtity between ECC and RSA
Date: Sat, 24 Jun 2000 10:06:32 -0700
DJohn37050 wrote:
> And in using just a TIME analysis, I point out that; (1) it is a common
> assumption to ignore space needs,
It is common as a simplifying assumption, but it is just sloppy
to ignore SPACE after someone has estimated for you.
> (2) this allows for a more direct mapping and
> hence high confidence in that mapping, and
The mapping is more direct because it is more disconnected with
the real world! (I assume the "mapping" is a comparison to the
complexity of other problems.) This give *less* confidence.
When you throw away info and make overly idealistic assumptions
then you are less confident of the result, not more.
> (3) doing so seems (to me) to require fewer assumptions.
Nonsense. You are assuming that the adversary has infinite SPACE.
That assumption could lead to excess engineering costs, or to
preferring a system that is actually less secure.
------------------------------
** 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
******************************
