Cryptography-Digest Digest #872, Volume #9 Mon, 12 Jul 99 20:13:04 EDT
Contents:
Re: I don't trust my sysadmin (Terje Mathisen)
Re: What is the "real" length of a key in 3-key 3DES? ("Thijs vd Berg")
Re: Stream Cipher != PRNG (wtshaw)
Re: Electronically Exporting crypto source (legally) (wtshaw)
Re: Base encryption (John Savard)
Re: What is the "real" length of a key in 3-key 3DES? (Jim Gillogly)
Re: New numeral base encryption (wtshaw)
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: How Big is a Byte? (was: New Encryption Product!) (Matthew Gates)
Re: randomness of powerball, was something about one time pads (Keith A Monahan)
Re: SHA-1 Implementation ([EMAIL PROTECTED])
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Analysis of ICE? ([EMAIL PROTECTED])
Re: Stream Cipher != PRNG ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: I don't trust my sysadmin
Date: Wed, 07 Jul 1999 09:00:23 +0200
Vernon Schryver wrote:
>
> >In article <[EMAIL PROTECTED]>,
> >David N. Murray <[EMAIL PROTECTED]> wrote:
>
> > ...
> >>My sysadmin is *not* allowed into my payroll database,
> >>however, I need to run a job every night against the
> >>payroll database (let's say a program that e-mail's
> >>employee review notifications to managers).
>
> As stated, it's hopeless.
Agreed, if the server itself ever has the data needed to decrypt/access
the payroll database, then you cannot stop a sufficently motivated
operator.
> n article <[EMAIL PROTECTED]>,
> Terje Mathisen <[EMAIL PROTECTED]> wrote:
>
> ] ...
> ]The only real solution (AFAIK) to this problem is to use
> ]application-level strong crypto on all the data in your database, this
> ]way the server and it's disks and backup tapes becomes pretty much
> ]worthless for anyone without the proper keys.
>
> Or anyone who has physical access to the computer and so can modify a
> driver to occassionally check the process table for your program, and if
> it's present, find your physical pages and copy interesting bits.
This is exactly why I want a setup where the database is just a place to
store some more or less interesting keys and the corresponding
encrypted blobs of data.
If the server _never_ has the key(s) used to encrypt the interesting
columns of your payroll database, then whoever operates that server
cannot grab that information either.
This does preclude anything like a nice SQL query, asking for 'All
pointy-haired managers with salary above $100K', since you can only test
the encrypted data for equality/non-equality to some specific value.
I.e. you cannot make this approach transparent to the application.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: "Thijs vd Berg" <[EMAIL PROTECTED]>
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: Mon, 12 Jul 1999 23:44:51 +0200
Kristof Burek <[EMAIL PROTECTED]> wrote in message
news:7mcv98$i06$[EMAIL PROTECTED]...
> anyone throw any light on how much more secure than 1-key 1DES 3-key
3DES
> [ Ec(Db(Ea( plaintext ))) ] really is - is there an estimate of an
> equivalent key-length assuming (1) chosen plaintext attacks are on
> offer (2) they aren't?
I know that 3DES is as hard as doubling the key-lenght of DES (56->112bit).
A proposed 2DES is not harder than DES. A brute force attact would take
2^112 / 2 guesses.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Stream Cipher != PRNG
Date: Mon, 12 Jul 1999 15:34:37 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I think we are cought up in terminology. From what I understand now a
> > PRNG normally forms some base structure, which is used in a 'combiner'
> > to form a non-linear output.
>
> No, it's not a matter of terminology; it's a fundamental misconception.
> If I had to build a stream cipher with military-strength security,
> I surely would *not* use any PRNG in its construction. (I might use
> some *shift registers*, but not in a PRNG configuration.)
> People who say that stream ciphers are all made that way simply have
> not seen a wide enough variety of stream cipher systems.
I would count on it that you have seen many, but not all. There is
nothing inately wrong with using a normal PRNG as a component if there is
enough state in the subsequent steps so that you cannot recognize the
generated series, or it is so mingled and mangled that other key
components are too big to reasonably brute force at the same time. The
theory is really duck soup for doing something like this.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Electronically Exporting crypto source (legally)
Date: Mon, 12 Jul 1999 15:40:41 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Alan J Rosenthal) wrote:
> [EMAIL PROTECTED] (Dmitri Alperovitch) writes:
> >So, then you should be able to slice your program apart into lines or even
> >bigger chunks of code that do not contain a fully working cryptographic
> >algorithm and it should be legal to electronically export each of these
chunks
> >individually!
>
> Each, but not all. Exporting one of them is fine, but useless. Exporting
> them all constitutes exporting the entire program. Your reductionism is
> leading you astray.
>
> Dialling '9' by itself on the telephone for no reason is acceptable behaviour.
> Dialling '1' by itself on the telephone for no reason is acceptable behaviour.
> Dialling '1' by itself on the telephone for no reason is acceptable behaviour.
> However, dialing 9, 1, 1 in sequence (emergency call, fire/police/etc) for
> no reason is not permitted. No contradiction. You can't just focus on the
> individual parts and refuse to see the overall structure.
Ah, the solution (it worked for 911), get your cat to do it. Seriously,
just how long will it be before some ten year old does something forbidden
in exporting crypto with significant results, and just what are you going
to do to him?
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Base encryption
Date: Mon, 12 Jul 1999 22:05:56 GMT
"User" <[EMAIL PROTECTED]> wrote, in part:
>This analogy fits in perfectly with the "base" I was referring to. A person
>who has no idea what a symbol in a different base represents cannot do
>a direct mapping between encrypted text base SYMBOLS to plain
>text base SYMBOLS. This is in addition to any encryption algorithm used.
That would solve the "all-zero one-time pad" problem discussed in
another thread, which I should be ashamed of starting...
However, *arithmetic* conversion between bases is time-consuming (it
uses multi-precision multiplications) and is, in general, not
closed-form.
My web page discusses special cases of base conversion useful in
armoring messages...
http://members.xoom.com/quadibloc/mi060201.htm
Start with using Huffman codes to compress a text message into binary
for encryption. Then, convert to the base-26 alphabet for some more
encipherment by classical methods.
As it happens, 2^47 is *very* slightly smaller than 26^10, so
conversion is extremely efficient. (I note as a warning that since
*some* reduncancy _is_ introduced, two separate keys should be used
for encryption before and after the conversion.)
Finally, four characters from the 26-letter alphabet can be quickly
converted to three characters from a set of 78, which is more
efficient than using 64 characters but should still be Internet-safe.
(78 is 3 times 26, so just break up one letter into three symbols from
1 to 3 and combine with the three others.)
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: Mon, 12 Jul 1999 15:27:31 -0700
Thijs vd Berg wrote:
>
> I know that 3DES is as hard as doubling the key-lenght of DES (56->112bit).
> A proposed 2DES is not harder than DES. A brute force attact would take
> 2^112 / 2 guesses.
Depends on your threat model. Can your opponent store 2^56 encrypted results
for the meet-in-the-middle attack you're suggesting? As a hint, that's
roughly 2^19 terabytes of data. If <I> had that much memory, I think I'd
choose to do something else with it than stick DES outputs in it for
the time it takes to make 2^112/2 guesses.
Van Oorschot & Wiener have a nice paper in a recent Journal of Cryptology
about how to modify this for reasonable amounts of memory in the 2DES
MITM attack, and the extension to 3DES is trivial.
--
Jim Gillogly
Mersday, 19 Afterlithe S.R. 1999, 22:20
12.19.6.6.7, 5 Manik 15 Tzec, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: New numeral base encryption
Date: Mon, 12 Jul 1999 16:13:03 -0600
In article <kcgi3.7811$[EMAIL PROTECTED]>, "User"
<[EMAIL PROTECTED]> wrote:
> I propose here a numeral "base" encryption using Virtual Calc 99
> and will describing an encryption using numeral conversion
> between base 64 to base 10 and to base 2.
>
....
>
> Here is the encrypted text in base 23 for the example phrase above:
> 94jch649c43jhhikeaf01b7a0ad0c984
A simple conversion is not as good as a keyed one. I would suggest that
you transpose the digits, but a floating result is not friendly to a fixed
length permutation, the types of key you are most likely to have.
I would not do what you did, my self-imposed rules, as ciphertext should
be in managable sized groups, and 32 characters is too long, could require
considerable padding for a short string. If you are going to interface
with other ciphers, keep the working groups as short as you can while
allowing ample keyspace.
By choosing natural passes through numerical mountains, base 10 is easier
converted to base 22. And my choice for input would be base 63. I just
looked...it on my charts, but not one I planned to do.
By keeping groups relatively short, you can deal with long passages quite
easily; I usually spec a minimum of 10 K characters in a message, for
array allocation purposes only. Hardly ever, do I see a real live message
done on the fly as more than an few K, most under 500 characters. Even at
that, putting it all in one unified number would be a bit awkward.
>
> Now to show you how strong this encryption method is (given that you
> already know how it works), I issue a small twist...
> I apply an operator function to it so that the base conversion has to
> deal with floating point, which will make the base conversion routine
> calculate to predefined precision...
>
> Here is the encrypted text: 2jpx5bu3g27j0szp7u1hpnwfw8.ch7wmy....
>
> Try giving me the plaintext to that!!!
> difficult aint it? since you dont know the
> simple operator used, and plus the base conversion
> had to go through floating point calculations.
> and you dont know the BASE!!
>
As long as it is mostly a simple conversion, even with a few choice of
operators, and/or the base is one of a few, you do not have enough
keyspace for the algorithm to useful if known. You are relying on the
liklihood that your opponents will lack the program, and some opponents
probably already have it, at least in principles that can be quickly
realized. It is rather basic, even if you choose algorithm obscurity as
part of your security protocol, that the one fact of finding it out does
not cause all of your ciphertexts to fall. But, you are into areas that I
relish.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Mon, 12 Jul 1999 21:51:05 GMT
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
[...]
> > I re-included your "can be re-written" above, so we
> > can see that
> > y += state[x++];
> > does _not_ have the same effect. You post-increment
> > where RC4 requires a pre-increment.
>
> It matters not when concerning security issues.
Can you prove that, or are you just making it up?
[...]
> > The extra
> > operation is trivial to optimize away. The choice
> > between correct in all cases and faster in some
> > cases is not a close call.
>
> If I put a &255 the compiler CAN NOT optimize it away.
Of course it can. What are you talking about?
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Matthew Gates)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Mon, 12 Jul 1999 23:15:52 +0100
In article <[EMAIL PROTECTED]>,
Boris Kazak <[EMAIL PROTECTED]> writes:
> Just as B(reast) has two N(ipples), B(yte) has two N(ibbles)
Breast singular, two nipples? You live near a
nuclear processing plant or something? [shudder]
(cue multi-nipple flamewar)
>
> ...probable, but not certain...
freakishly deformed. I speak from experience.
-Matt
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: randomness of powerball, was something about one time pads
Date: 12 Jul 1999 23:29:00 GMT
I have to quote a local right-wing conservative radio talk show host.
"The lottery is a tax on the poor."
Take the same money you spend on the lottery, put it into a savings account,
a CD, or anything that has a (somewhat) gauranteed return on it. Even if
the return is low, it will pay out more in the end...
Keith
P.S. http://www.warroom.com is the link for the radio show, fyi.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: SHA-1 Implementation
Date: Mon, 12 Jul 1999 22:34:43 GMT
In article <7mde2q$fsh$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Keith A Monahan) wrote:
> When doing the padding inside the SHA-1 function, AC says, "First, the
> message is padded so that its length is just 64 bits short of being a
multiple
> of 512."
>
> I know this is probably implied here, but just to be clear, this means
that
>
> The message must be padded so that it's length is EXACTLY 64 bits
short of
> 512.
>
> ...which means that if your original message length is, say, 482 bits
long,
> you must pad all the way up to the next multiple, in this case 1024-64
or
> 960.
>
> Then, at that point, the 64-bit representation of the original length
is added.
>
> It's interesting that in my example that the padding (including the
length
> count) is 542 bits, some 60 bits more than the original message!
>
> Just thinking out loud...
>
> Master of the Obvious,
>
> Keith
>
>
I think you have it right. You might want to inspect
my implementation at www.afn.org/~afn21533/sha1.zip; this
implementation checks all the proper vectors, including
the one of 10^5 'a's/ Also see the sha1pass.zip variation
meant to hash a passphrase using the SHA1 algorithm.
--
Robert G. Durnal
Web pages at www.afn.org/~afn21533
and members.tripod.com/~afn21533
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Mon, 12 Jul 1999 22:37:57 GMT
In article <7mdo04$bc$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > It matters not when concerning security issues.
>
> Can you prove that, or are you just making it up?
My logic is what makes 'y += state[++x]' more secure then 'y += state
[x++]'? The first is normally faster for some compilers, but they both
have a similar effect. All 'x' is used for is to make sure each
element is used at some point.
I know the standard (well accepted standard) uses the first...
> > If I put a &255 the compiler CAN NOT optimize it away.
>
> Of course it can. What are you talking about?
Well it would have to optimize it by only using the lower 8 bits. In
turbo c for example if I did
c = (unsigned char) (a + b);
It would make
; {
; c = (unsigned char) (a + b);
;
mov al,byte ptr DGROUP:_a
add al,byte ptr DGROUP:_b
mov ah,0
mov word ptr DGROUP:_c,ax
And
c = (a + b) & 255;
would make
; c = (a + b) & 255;
;
mov ax,word ptr DGROUP:_a
add ax,word ptr DGROUP:_b
and ax,255
mov word ptr DGROUP:_c,ax
Both of which are equally as fast. Either way you have to exclude or
and against (or mod) the part you need.
How would a C compiler optimize
c = (a + b) & 255
in your books?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Analysis of ICE?
Date: Mon, 12 Jul 1999 23:25:27 GMT
I was just wondering if there ever was any analysis of ICE done?
According to the paper [1] it is faster then DES, resistant to attacks
and has a larger keyspace. If it truly is better then DES (the code is
quite compact BTW) could it not be a suitable replacement for DES?
Since it's a 64-bit block cipher it's not suitable for some newer tasks
but for drop in replacement? It has no weak keys (like Blowfish), and
is not patented (like RC5).
I have the paper if anyone wants to look at it. It's well written.
Tom
[1] The Design of the ICE Encryption Algorithm, Matthew Kwan.
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Stream Cipher != PRNG
Date: Mon, 12 Jul 1999 23:02:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> The combiner might just be a simple XOR, and in that case the stream
> cipher and its associated PRNG might have the same name.
Well xor is a bad combiner. A combiner is used to increase the linear
complexity when using PRNGs. See the various LFSR generators as
presented in Sch96.
> But as DAG has pointed out, there are other ways of having stream
> ciphers that don't involve a PRNG at all, as I also noted by
> describing the "self-synchronizing" type of stream cipher, where a
> function of several previous ciphertext bytes is applied to each byte
> of plaintext to encipher it.
Well if the actual enciphering process requires knowledge of previous
or current ciphertext is it a stream cipher or a mini-block cipher in
CBC mode?
I always pictured that the plaintext/ciphertext does not effect the
state, otherwise it could be used in a chosen plaintext attack to gain
knowledge of the state.
What is the distinction anyways? Am I right in saying that a stream
cipher is a time dependant permutation of the input (whether by a PRNG
or some other means) and that a block cipher is a fixed-key dependant
permutation of the input?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
