Cryptography-Digest Digest #947, Volume #13 Tue, 20 Mar 01 05:13:01 EST
Contents:
Re: Idea (Mok-Kong Shen)
Re: Codes that use *numbers* for keys (Mok-Kong Shen)
Re: Am I allowed to put any encryption software of my own creation on my (Mok-Kong
Shen)
Re: Codes that use *numbers* for keys (Juuichiketajin)
Re: Defining a cryptosystem as "broken" (Mok-Kong Shen)
Re: Codes that use *numbers* for keys (Mok-Kong Shen)
Re: Are prime numbers illegal ? (Nicholas Sheppard)
Re: SSL secured servers and TEMPEST (Frank Gerlach)
Re: FIPS 140-1 does not adress eavesdropping (Frank Gerlach)
Re: AES encryption speed vs decryption speed ("Brian Gladman")
A future supercomputer (Mok-Kong Shen)
Re: Defenses Against Compromising Emanations of the Private Key (Frank Gerlach)
Re: Idea ("Nathan Dietsch")
Re: Codes that use *numbers* for keys ("Henrick Hellström")
Re: Codes that use *numbers* for keys (Joe H. Acker)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Tue, 20 Mar 2001 08:30:52 +0100
amateur wrote:
>
> Don't forget that with my idea the same clear could produce multiple
> cyphertext.
> Schneier is defining restricted algorithm when algo is kept secret.
> That's not my case.
> All my algo is public. The secret who is to find and distinguish two
> categories of symbols is not secret at all.
> But the sender has the freedom to imagine any kind of two categories
> before encrypting.
> This secret is disclose if the recipient has the key.
> All modern cryptography is based on power of computing.
> What I'm proposing is to found a new cryptography based on the inability
> of computer to analyse a text trying to distinguish two categories.
> Computer has no this attribute. So the cryptanalist even if he use the
> computer is helpless. The only strategy for him is to try to guess what
> a sender has choosen to encrypt every bit.
> And this domain is infinite.
> You have multiple combinations using only the characters of ASCII table.
> If using others codes, you have to understand thas it's quite impossible
> to attack.
If the symbols in two categories are known, then the scheme
is very much easier for the oppoent to work with than the
case where these are unknown, since he has to try only
two cases. Since one can easily generate two unknown
categories of symbols (having constant or variable number
of bits) with a key, what is the use of your scheme at all?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Codes that use *numbers* for keys
Date: Tue, 20 Mar 2001 08:39:48 +0100
Juuichiketajin wrote:
>
[snip]
> Why are key lengths always given in bits? Why not a code that takes, oh
> say, 60 decimal digits for a key? I can relate to 60 digits, not to so
> many bits.
Modern ciphers are implemented with computer hard/software.
These work with bits. Hence bit is a natural measure. You
can always convert between the bases of number systems.
Does an American visiting London ask why the prices are not
in dollars?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Am I allowed to put any encryption software of my own creation on my
Date: Tue, 20 Mar 2001 09:06:16 +0100
Dennis Ritchie wrote:
>
[snip]
> The document is tedious to
> read, but rather more liberal in its requirements than
> one might expect. Things have changed.
Fine to know. This change is presumably sort of: If the
mountain doesn't come to Mohammed, then Mohammed will go
to it.
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Juuichiketajin)
Subject: Re: Codes that use *numbers* for keys
Date: 20 Mar 2001 08:15:41 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>
>
>Juuichiketajin wrote:
>>
>[snip]
>> Why are key lengths always given in bits? Why not a code that takes, oh
>> say, 60 decimal digits for a key? I can relate to 60 digits, not to so
>> many bits.
>
>Modern ciphers are implemented with computer hard/software.
>These work with bits.
They need not.
I have at my disposal a financial and a scientific calculator that both work
in decimal. I have reason to believe that the internal number-storage format
is decimal.
Even granting that binary divisions are somehow superior, I suspect that the
REAL reason bits are used, rather than bytes or at the very least nibbles, is
so the sizes sound bigger.
When you hear "48-bit key", don't you find yourself performing some mental
calculation as to the value of 2^48 in some other system?
Hence bit is a natural measure. You
>can always convert between the bases of number systems.
>Does an American visiting London ask why the prices are not
>in dollars?
>
>M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Defining a cryptosystem as "broken"
Date: Tue, 20 Mar 2001 09:29:47 +0100
Joseph Ashwood wrote:
>
> It is my belief that the model itself should supply for it's own
> re-evaluation timeframe. For some systems it is vital that it be reviewed
> continually, for others it may only be necessary that it be reviewed
> annually. If the path was dependable, say we know that in 5 years X will
> occur and 128-bit Rijndael will not longer be secure, then I would suggest
> choosing a decommision date ahead of time, however we don't even know what X
> is, let alone when it will happen or even if it will affect Rijndael at all,
> so it takes periodic vigilance to determine when the decomminsion date has
> arrived.
>
> Based on this a thread/attack model needs to take into account the current
> state of the art and a buffer-zone, any erosion into the buffer zone
> immediately makes the decomission date immediate or as close to it as
> possible. With a solid threat/attack model it is generally possible to
> select a replacement cipher or protocol very quickly.
You are at least right in theory. In practice, I think
however that there are essential problems to eliminate
the subjectivity that is called for where the needed
informations for an entirely objective decision are wanting.
Given that a solid threat/attack model yields solid and
precise results, one is yet left with the question whether
that model really exactly applies to the applications one
has in hand.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Codes that use *numbers* for keys
Date: Tue, 20 Mar 2001 09:34:20 +0100
Juuichiketajin wrote:
>
> They need not.
> I have at my disposal a financial and a scientific calculator that both work
> in decimal. I have reason to believe that the internal number-storage format
> is decimal.
It would be very interesting to know a modern processor
working internally on decimals and not on bits. Ask your
manufacturer and please post your results (including the
name of chip) if the answer is positive.
M. K. Shen
------------------------------
Date: Tue, 20 Mar 2001 12:50:53 +1100
From: Nicholas Sheppard <[EMAIL PROTECTED]>
Subject: Re: Are prime numbers illegal ?
On Mon, 19 Mar 2001, Sundial Services wrote:
> It is, in a word, the kind of argument that will cause a judge to smile
> in a dangerous sort of way.
That's 17 words, by my count.
Are you referring to Douglas' argument, or John's, or the original
article's?
> It's a politically-motivated piece of legislation if ever there was one,
Since the legislature is part of the political system, it seems hard to
image a piece of legislation that isn't "politically-motivated". Random
laws, anyone?
--
Nicholas Sheppard | Ph: +61 2 4221 5290
Research Fellow | Fax: +61 2 4221 4170
School of Information Technology & Computer Science | E-mail: [EMAIL PROTECTED]
The University of Wollongong, Australia | WWW: www.uow.edu.au/~nps
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: Tue, 20 Mar 2001 09:52:39 +0100
> The thing is, you can't install them in the embassy basement. At best
> you can install them in a nearby city. Still think you can pick up
> intelligible conversation?
I meant e.g. the US embassy in moscow. Or the russian in Washington.
As I said, this would only hold true, if they would repeat their conversations a
lot of times. This wasn't really serious...
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: FIPS 140-1 does not adress eavesdropping
Date: Tue, 20 Mar 2001 09:58:22 +0100
> However, I can tell you that hardware designers are acutely aware of
> these attacks and do what they can to protect against them, whether or
> not 140-1 requires it.
In which world are you living ? In the world of perfectness or in the world of
deadlines ? We are all aware of the marketing statements of commercial crypto
companies - why do you expect that they spend *any* money on limiting emanations
as long as nobody actually *measures* it ?
> I'm somewhat more concerned about firmware back doors being built into
> devices.
Then better start doing you own CPU, memory, display, OS, email client.....
For governments this is actually a necessity, from my point of view :-)
> I'd like to see the sci.crypt community design its own
> device with standard parts
Standard parts like the very popular CPU, which could be halted by an instruction
sequence of a user-level program ? (And might expose something worse to the
three-letter agencies ?) There are no standard parts you can 100% trust into.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES encryption speed vs decryption speed
Date: Tue, 20 Mar 2001 09:21:45 -0000
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:996gu1$mnu$[EMAIL PROTECTED]...
>
> Brian Gladman <[EMAIL PROTECTED]> wrote in message
> news:XBut6.409$Ph.30133@stones...
> >
> > "Thierry Falissard" <[EMAIL PROTECTED]> wrote in message
> > news:995g2b$gpp$[EMAIL PROTECTED]...
> > > Unless I am badly mistaken, I have the impression
> > > that decryption with AES must be somewhat slower
> > > than encryption. Computations in the InvMixColumns
> > > transformation should take more time than in MixColumns,
> > > because of the matrix that is used for multiplication.
> > > Could somebody confirm this ?
> >
> > For high speed implementations the encryption and decryption operations
> > are about the same in speed terms but key setup for decryption takes
> > a lot longer than for encryption.
>
> I assume that by "high speed implementation", you mean hardware.
No, I was distinguishing between high and low speed software
implementations.
> For software, once the key schedule has been run, it doesn't really matter
> which direction you use the subkeys (except for memory constrained
> situations where you can't express the full key schedule at once, which
> hardly qualify as "high speed implementations").
For low speed the cipher can be implemented to use the same key schedule for
encryption and decryption. Unfortuneatly, however, the high speed form of
the cipher using tables has a different key schedule for decryption - one
that is obtained by running the inverse mix column operation on the
encryption round keys (except the first and last).
> > Obviously the impact this will have will depend on whether the
decryption
> > mode of the algorithm is needed and, if it is, how often the keys are
> > changed relative to the number of blocks being processed.
>
> Actually, if keys are going to be used in decryption mode, they can be
> preprocessed by stepping them into the form they have at the end of the
key
> schedule. Then, when performing a decryption, you simply step through the
> key schedule backwards, generating the subkeys in the order you use them.
> That way, the major pain can be rolled into key setup time, and not
> everytime you change keys.
> Or, is there something subtle with the AES key schedule that I missed?
Yes! Where decryption speed is not an issue, I agree that it is often
sensible to do what you suggest. But if you use a table based decryption
scheme you will also need to run the inverse mix column operation on most of
the key schedule words before they are used in the reverse difrection.
If you change keys infrequently and have the space to store the whole
forward and inverse key schedules then this will have no significant impact
on performance. But at the other extreme - one key per block - decryption
speed will suffer a lot since either a slow implementation will have to be
used or one using tables but with a costly modification of the key schedule.
My expereince shows that which of these is better depends on circumstances.
Brian Gladman
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: A future supercomputer
Date: Tue, 20 Mar 2001 10:22:11 +0100
A news says that IBM will build in four years a supercomputer
Blue Gene with over one million processors for research in
protein structures.
M. K. Shen
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Defenses Against Compromising Emanations of the Private Key
Date: Tue, 20 Mar 2001 10:14:44 +0100
Lyalc wrote:
> Averaging out noise has a finite limit in it's usefulness. The signals of
> interest are transient, thus they to will be averaged when the occur.
> A regular, or steady state signal has a S/N improvement when averaged - the
> noise average increased by around 3db, the regular features of the signal
> increase by around 6 db.
This might be true for a very specific method of signal recovery, but what we
have to think of is what is possible in theory. Noise does not equal noise. Even
if the frequency spectrum of one signal matches the spectrum of the target
signal very much, slight differences can be exploited. This is done by CDMA
telephones every day.
>From an information-theory point of view, it does absolutely not matter how you
encode a signal, the information thransmission rate is defined by the SNR and
Bandwith. (Which are difficult to calculate, looking at the fourier transforms,
of course)
> IMHO, unless there is a credible way of knowing when a key operatiion is
> going to happen, we end up with averaged noise and averaged signals of
> interest.
This is quite true, but whatabout the signals of the Host machine, such as the
SCSI controller of the host initiating an RSA operation in the crypto
coprocessor ? This could provide the "hook" for doing averaging/correlation.
> Yes, the CA must be operating hundreds of times if the certificates are
> temporary.
I was thinking of a hierarchical scheme of temporary certificates, generated by
the website itself.
> See the above point on regular vs transient averaging. OTDRs have a regular
> signal to work with. Spread sprectrum, CDMA etc has predictable, specially
> crafted characteristics which are exploited to advantage. It beggars
> belief that a hardare crypto card also has such transmission
> characteristics, since I can't see they'd be part of the functional spec.
> e.g. a start signal, a stop signal, and a timing signal.
Shannon does not differentiate between synchronous and asynchronous signals. It
just doesn't matter, from a theoretical point of view. I agree that a CRT signal
is trivial compared to an SSL private key, but who said that dull averaging is
the only way of attack ?
> And there is 100 CPU, 200 power supplies (CPU and Monitor), disk drives,
> et al all adding to the noise problem
Simple filtering in the frequency domain can eliminate most of the "noise"
sources. We are using this every day when listening to the radio or sitting in
front of the TV.
Only *deliberate* jamming can provide useful assurance of SNR.
------------------------------
From: "Nathan Dietsch" <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Tue, 20 Mar 2001 20:51:42 +1100
Scott,
I think you may have misinterpreted the use of the word "Qualified" by both
amatuer and John. AFAIK they were using it in the sense of "Are you good
enough?" rather than "Do you have a piece of paper from a university?".
Just my two cents.
Kind Regards,
Nathan
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (John Joseph Trammell) wrote in
> <[EMAIL PROTECTED]>:
>
> >On Sun, 18 Mar 2001 12:59:56 -0400, amateur <[EMAIL PROTECTED]> wrote:
> >> If you are so confident, I will send you encrypted message with
> >> the same algo and decrypt it.
> >
> >If you are so confident, prove to me that you're qualified to
> >write a cryptosystem. :-)
> >
>
> I hate it when people think it is necessiary to prove one
> is qualified to do something. Just what the hell does that mean.
> If the guy is a live he is qualifed. Pices of paper usually
> don't mean shit. Qualifications are used to keep the community
> closed. Of couse the pompous assholes will find fault with many
> of so called ametur stuff and use that as an excuse to never really
> check what many ametures are doing.
> Taking teaching as an example. I am a retired engineer worked
> on programming inertial guidance systems on missles and aircraft.
> I used calculus every day. I tutored my kids in it and they passed
> the AP tests and got college credit no sweat California.
> Here in Texas they have a shortage of "qualifed math teachers".
> I spent a month and some bucks trying to get hired since they
> say they need math teachers. First roadblock every time you turn
> around the system wants more money. They wanted my college transcripts
> I give them to them. They asked after I called them a few weeks
> later that I did not have algebra or trig. I started college on a
> math scholarshop and took calculus off the bat. That seened to
> confuse them. Then they sent a list of classes I needed to take
> and a schedule of fees in the thousands of dollars I would have to
> pay. Thats just to get started. On top of that not really sure there
> is a job there though they assure me that one is there. Guess what
> your forced to pay into the teachers retirement fund. You can' get
> full retirement till you work 20 years. Well as you can see I
> was not applying for english teacher. But I was dam good at math
> and I can see why they have a shortage of math teachers. You have
> to go though hell to get the job the pay is shit and math really
> is not that much of a requirement. And if your all ready retired
> they want to humilate you by forceing you to pay into a retirement
> system you wont live long enough to get a dime from. In my case
> I don't mind the low pay. I am retired. I would do it for half the
> pay. But I am short about 4 years of having 40 quarters for SSI
> so way the hell work at a full time job paying into a system you
> can never use. The point is one can chase a carrot only so long.
> It reminds me of a friend where I use to live in CA. They had
> a jewlery store. THe threat of robbery very high. THey tried to
> get a permit to cary a gun. They spent years paying fees getting
> evaluated by shrinks. But they where always one step short. Till
> an insider told then they had the wrong politics and there would
> always be another step. While they gave up until one day a friend
> told they they had a permit from country. The freind inrodcued them
> to the count sheriff. A few days later they got the permit.
>
> SORRY FOR THE RANT
>
>
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> Scott famous encryption website **now all allowed**
> http://members.xoom.com/ecil/index.htm
> Scott LATEST UPDATED source for scott*u.zip
> http://radiusnet.net/crypto/ then look for
> sub directory scott after pressing CRYPTO
> Scott famous Compression Page
> http://members.xoom.com/ecil/compress.htm
> **NOTE EMAIL address is for SPAMERS***
> I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Codes that use *numbers* for keys
Date: Tue, 20 Mar 2001 11:01:47 +0100
"Mok-Kong Shen" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
>
>
> Juuichiketajin wrote:
> >
>
> > They need not.
> > I have at my disposal a financial and a scientific calculator that both
work
> > in decimal. I have reason to believe that the internal number-storage
format
> > is decimal.
>
> It would be very interesting to know a modern processor
> working internally on decimals and not on bits. Ask your
> manufacturer and please post your results (including the
> name of chip) if the answer is positive.
>
> M. K. Shen
Most modern processors work internally on bits. Most modern processors also
work internally on decimals. Intels x86- & x87-processors support Binary
Coded Decimals, instructions like e.g. DAA, decimal adjust after addition,
etc.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: Codes that use *numbers* for keys
Date: Tue, 20 Mar 2001 10:59:51 +0100
Juuichiketajin <[EMAIL PROTECTED]> wrote:
> Even granting that binary divisions are somehow superior, I suspect that the
> REAL reason bits are used, rather than bytes or at the very least nibbles, is
> so the sizes sound bigger.
> When you hear "48-bit key", don't you find yourself performing some mental
> calculation as to the value of 2^48 in some other system?
You're somewhat right if you exchange "key" with "passphrase". In many
language systems, one character (like a Hiragana symbol) is represented
by two or more bytes, but the maximum entropy actually is defined by
what the user can enter, not by the number of bits used to represent the
characters. Same for plain ASCII: the user can only enter a small
subset of the whole character range 0...255 (or 0..127 resp.). That's
something an implementor has to be aware of.
Of course, you have to hash the passphrase and try to "stretch" it.
Nevertheless, when the user just enters 4 or 5 symbols as passphrase,
the cipher will be broken by brute force attack. And as the user has to
be able to remember his passphrase, a clever guessing attack is likely
to succeed against many passphrases that are much longer. That means,
that in real-world applications, the theoretical keyspace is only good
for measuring strength against direct attacks against the possible keys,
not for measuring attacks against the passphrase.
But in order to be aware of such issues, you need to use bits as units.
Heck, on a strange system, a character might even be represented as 4
bytes, but only 1 of them actually used. If you don't strip the
remaining 3 off, the attacker knows a lot of plaintext at regular
patterns that has been fed into the hash fuction.
Regards,
Erich
------------------------------
** 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
******************************
