Cryptography-Digest Digest #948, Volume #13 Tue, 20 Mar 01 08:13:01 EST
Contents:
Re: Codes that use *numbers* for keys (David Schwartz)
Re: Idea (David Schwartz)
Re: NSA in the news on CNN ("Mxsmanic")
Re: Fast and Easy crypt send (Joe H. Acker)
Re: AES encryption speed vs decryption speed (Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?=)
Re: [OT] Why Nazis are evil (Benjamin Goldberg)
Re: Codes that use *numbers* for keys (Juuichiketajin)
Re: AES encryption speed vs decryption speed ("Brian Gladman")
Re: Is SHA-1 Broken? (Volker Hetzer)
Re: Codes that use *numbers* for keys ("Tom St Denis")
Re: Codes that use *numbers* for keys (Paul Schlyter)
Re: OT: TV Licensing - final answer - sorry for xpost (Richard Herring)
Re: How to eliminate redondancy? (Benjamin Goldberg)
Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long) (Benjamin
Goldberg)
Re: AES encryption speed vs decryption speed (Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?=)
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Codes that use *numbers* for keys
Date: Tue, 20 Mar 2001 02:07:21 -0800
"Henrick Hellström" wrote:
> 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.
Actually, these operations are required because the processors do not
support binary coded decimals. If they did, there would be no need to
adjust anything. The 'DAA' function, for example, transforms an input
string of bits into an output string of bits.
You can use these bits to represent decimals if you want, and the
processor may or may not help you make sense of this. But that is a far
cry from using decimal representation internally.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Tue, 20 Mar 2001 02:09:38 -0800
"SCOTT19U.ZIP_GUY" wrote:
>
> I hate it when people think it is necessiary to prove one
> is qualified to do something.
Why? Because you can't prove you're qualified?
> Just what the hell does that mean.
It means that you have to show that you're qualified to do something.
How hard is that to understand?
[snip of rant]
That's nice, but it has nothing to do with proving that you are
qualified to do something. In fact, your problem seems to be that you
were never given the oppurtunity to prove that you were qualified. So
your rant actually argues against the point you claim it supports.
DS
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: NSA in the news on CNN
Date: Tue, 20 Mar 2001 10:22:19 GMT
I saw it on CNN's Web site. I don't watch CNN on TV, so I don't know
what the broadcast schedule might be (indeed, I'm not even sure that it
appears on the air, as opposed to the Web site, but I don't really
know).
"jtnews" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Can you email me the program time?
> thanks!
>
> Mxsmanic wrote:
> >
> > CNN has a special series on the NSA (how times change!) this week,
which
> > may generate some interest in PGP, as I presume they'll eventually
get
> > around to mentioning the program. They are supposed to talk about
> > encryption in days to come, but I don't know to what extent. The
series
> > even shows pictures from inside the NSA! Those people at Fort Meade
> > must be getting desperate for funding, or something!
>
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: Fast and Easy crypt send
Date: Tue, 20 Mar 2001 11:26:24 +0100
amateur <[EMAIL PROTECTED]> wrote:
> The text is encrypted with my algo. Read before attaching.
> The ouput you are looking for is random.
> Every bit is crypted with symbol which is choosen randomly.
> If I choose odd and even to encrypt. Then the number 0 or 2 or 4 or 6 or
> 8 represent the bit 0.
> So the ouput E you are trying to test is random.
> That's what you don't understand.
I'm an amateur as well. Here is what doesn't get into my head: Why the
heck to you continuously think that the attacker cannot recognize that
you are using two categories (like odd and even numbers, open and closed
letters, and so on)?
You seriously underestimate the intellectual abilities of your
adversary. Just imagine that it's not your sister that is analysing your
cipher, but dozens of mathematicians that have been working in the field
of cryptography for dozens of years. They are likely to understand your
two-category scheme at the glance of an eye, especially since they
regularly read sci.crypt and know your cipher anyway.
You need to read a good book on the history of cryptography.
Regards,
Erich
------------------------------
From: Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?= <[EMAIL PROTECTED]>
Subject: Re: AES encryption speed vs decryption speed
Date: Tue, 20 Mar 2001 12:41:09 +0200
Brian Gladman wrote:
> 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).
It is possible to use the same round keys in both encryption and decryption
(except in reverse order in decryption) as described in the specification: in
decryption AddRoundKey is just executed before InvMixColumn. This way the
InvMixColumn is not needed for the round keys at all. Why is it then faster to
use different key schedule in decryption? I guess changing the order of the
round key addition and inverse mix column shouldn't slow the cipher down and the
table is only accessed in reverse order.
What I think:
If you have two tables, one for encryption round keys and one for decryption
round keys, it is reasonable to change the order of AddRoundKey and InvMixColumn
in deryption and get rid of the decryption key table. This will not affect the
deryption speed but saves memory.
-- Panu Hämäläinen
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: [OT] Why Nazis are evil
Date: Tue, 20 Mar 2001 11:31:12 GMT
Your response clearly demonstrates the point I was making in the post
you responded to -- specifically, whether certain things are good or bad
(or "evil") is something that different people people have different,
possibly irreconcilable, beliefs about.
Further, I think we can all agree that there's no possibility of all of
coming to an agreement one way or another about right and wrong, any
time this century. This seems to indicate -- to me, at least -- that it
is now time to end this discussion and this thread.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: [EMAIL PROTECTED] (Juuichiketajin)
Subject: Re: Codes that use *numbers* for keys
Date: 20 Mar 2001 11:46:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
>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
I mean, you know how in a spreadsheet program, you have letters used as
base-26 digits? I mean, use kana as base-44 (or higher) digits. And my
guess (it is just a guess) is that it would be easy to come up with
combinations like "ma-ri-ko-ha-su-wo-no-mu-ko-to-ga-da-i-su-ki-da" which
are EASY to remember and have HIGH density!!!! Or is it high density?
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES encryption speed vs decryption speed
Date: Tue, 20 Mar 2001 11:57:15 -0000
"Panu Hämäläinen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Brian Gladman wrote:
> > 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).
>
> It is possible to use the same round keys in both encryption and
decryption
> (except in reverse order in decryption) as described in the specification:
in
> decryption AddRoundKey is just executed before InvMixColumn. This way the
> InvMixColumn is not needed for the round keys at all. Why is it then
faster to
> use different key schedule in decryption? I guess changing the order of
the
> round key addition and inverse mix column shouldn't slow the cipher down
and the
> table is only accessed in reverse order.
>
> What I think:
> If you have two tables, one for encryption round keys and one for
decryption
> round keys, it is reasonable to change the order of AddRoundKey and
InvMixColumn
> in deryption and get rid of the decryption key table. This will not affect
the
> deryption speed but saves memory.
Wrong since more than one set of tables will be needed if the order of the
operations is not reversed.
If the key addition is the last step in the round function, one set of
tables can be used to go from four 8-bit input bytes in each round to each
of the 32-bit output words for the round. In basic terms the round function
has the form:
output word(n) = table0[byte0(n)] xor table1[byte1(n)] xor
table2[byte2(n)] xor table3[byte3(n)] xor round_key
That is, four table lookups and 5 xors per output word - 16 table lookups
and 20 xors per round for 128 bit blocks.
If however the round key addition and inverse mix column steps are not
reversed, then two table lookup steps are needed - one for the operations
before key addition and another for the inverse mixing operation after key
addition.
Although some of these steps are trivial (and might not be table driven),
the very fact that two steps are needed in place of just one has a
significant impact on the operation count for the round function and will
typically slow it down considerably.
Brian Gladman
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Is SHA-1 Broken?
Date: Tue, 20 Mar 2001 13:08:27 +0100
Steve Meyer wrote:
>
> On Mon, 19 Mar 2001 17:19:39 -0500, Jim Steuert <[EMAIL PROTECTED]> wrote:
> >No, you didn't miss anything. I did. I jumped to conclusions.
> >
> <snip>
>
> >
> >Do you know of any research using BDD's to invert cipher or
> >hash functions? I am off to learning more about BDDs.
>
> There has been quite a large amount of experiene with BDDs in electronic
> design. BDD have a serious problem is determining the value computed by
> a combinatorial electronic circuit. Namely, size of BDD's can and
> does grow exponentially with the number of inputs. In electronic
> design, designers learn to design in such a way as to minimize this
> exponential explosion. But converting a encryption algorithm into
> a BDD may be an interesting test for quality of encryption algorithm.
> /Steve
Right now, in electronic design, only one special case is known,
where the size of the bdd explodes exponentially. It's multiplication.
IMHO, as long as ciphers mix shifts and xors and all that stuff,
they're probably secure. However, anybody that reads this and uses
a model checker at work can download NSA's reference vhdl implementations
and try them on it.
Shouldn't be that difficult.
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Codes that use *numbers* for keys
Date: Tue, 20 Mar 2001 12:20:30 GMT
"Juuichiketajin" <[EMAIL PROTECTED]> wrote in message
news:996l6l$rdd$[EMAIL PROTECTED]...
> Several months ago, I saw on the Web some sort of code called Manticore.
> I am not 10% sure, but I think it used a PGP-like algorithm. But what I
> like about it more than PGP is that it uses actual *numeric* *numbers*
> for code keys, not weird number / letter / whatever combinations that
> can't be pronounced. Even hiragana would be an improvement, as long as
> they left out Wo and N. (I got this idea from a video game that has
> kana passwords.) You can read off a string of digits or kana, not
> alphabet soup. And if you use digits, they should probably be decimal
> digits. And octal is OK; all octal digits are also decimal. Just mark it
> as octal.
> Do you know where I can find Manticore, or some code that uses numeric
> numbers for keys?
> 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.
>
First off "PGP-like algorithm" is a meaningless term so you should drop it.
Second something alot of people just don't seem to get regardless of the
base you use the message is the same i.e 11 in binary is 3 in decimal.
Simple stuff. PGP uses base64 to encode raw binary data in an ASCII format.
The data "means" the same it's just represented differently.
Tom
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Codes that use *numbers* for keys
Date: 20 Mar 2001 12:11:59 +0100
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
> "Henrick Hellstrvm" wrote:
>
>> 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.
>
> Actually, these operations are required because the processors do not
> support binary coded decimals. If they did, there would be no need to
> adjust anything. The 'DAA' function, for example, transforms an input
> string of bits into an output string of bits.
>
> You can use these bits to represent decimals if you want, and the
> processor may or may not help you make sense of this. But that is a far
> cry from using decimal representation internally.
The 6502 microprocessor did have a "decimal flag" which initially was
clear. If set, its ADD/ADC/SUB/SBC/INC/DEC operations would work in
BCD instead of binary. Of course the 6502 did work internally in
binary anyway, but you didn't have to cann any "decimal adjust"
instructions after the add/sub operations when the decimal flag was
set. Btw the 6502 didn't have any "decimal adjust" operations,
instead it had the decimal flag.
The very earliest computers (ENIAC and friends) were often hardwired
to work in BCD. Their opcodes were in BCD too.
EBCDIC (the character code used by IBM mainframes) means "Extended
Binary Coded Decimal Interchange Code": it was an extension of BCD
from 1 to 2 nibbles. Most of the character codes used in EBCDIC do
have a low nibble in the range 0 to 9.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: OT: TV Licensing - final answer - sorry for xpost
Date: 20 Mar 2001 12:13:24 GMT
Reply-To: [EMAIL PROTECTED]
In article <99627r$mis$[EMAIL PROTECTED]>, Paul Schlyter ([EMAIL PROTECTED]) wrote:
> In article <99510k$l0n$[EMAIL PROTECTED]>,
> Richard Herring <[EMAIL PROTECTED]> wrote:
>
> > In the days when people used TVs as computer monitors, there were no
> > exceptions to the law for such special cases. Later it was amended
> > to provide specific exemptions for using the TV as a video monitor.
>
> Wasn't the determining factor whether the TV could receive RF
> signals? I.e. if you had a monitor with baseband input only, no
> license was needed,
That much is certainly true. But I'm talking about using a domestic
TV-with-tuner, not a true baseband monitor.
> but if the monitor also included a tuner so you
> could actually receive TV transmissions, then a license was needed.
No. We're talking law here, not logic :-(
The legal test was not possession of a tuner, but whether you had
"installed a station". As I said, to find out what that means you
have to hire a lawyer. My guess is that at a minimum you would
have to connect an antenna.
>
> Liwewise, a license would be needed for a VCR if the VCR had an
> integral tuner (as most VCR's do).
That is true.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Tue, 20 Mar 2001 12:30:40 GMT
Joe H. Acker wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
> > SCOTT19U.ZIP_GUY wrote:
> > >
> > > see.signature (Nicol So) wrote in
> > > <[EMAIL PROTECTED]>:
> > >
> > > >
> > > >That's not true. Lossless compression works exactly by reducing
> > > >the redundancy in the representation of information.
> > > >
> > >
> > > Actaully most Lossless compressors that are not bijective
> >
> > A compressor which is lossless is bijective.
>
> ...if you compare possible outputs of the compressor with possible
> inputs of the compressor.
If you try to claim that the set of *all* streams is the range, when it
isn't, then of course you lose the "onto" property, since some streams
simply don't get produced. An incorrect definition of range produces an
incorrect conclusion regarding the onto property, and hence the
bijection property.
If you use definitions other than those that the scientfic community
accepts, you can make any sort of claims you like.
Consider the function F(x) = x + 0.5, with the domain of all integers,
and the range of those reals which are an integer plus 0.5. This
function is one-to-one, and onto, and is a bijection, because all of the
properties needed to be one-to-one and onto are fulfilled, and anything
which is one-to-one and onto is a bijection. However, David Scott would
say, "but the inverse doesn't map all real numbers to integers, so it's
not a bijection" because he likes being an ass. If you use some
definition of range other than the correct one, you lose the onto
property. David doesn't have the mental capacity to understand that the
range and domain are allowed be different, and that the function can
still be bijective if this is so.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long)
Date: Tue, 20 Mar 2001 13:00:47 GMT
In some of your ciphers you have an operation of the form: for each of
the N bytes of the block, substitute the byte through a different sbox,
where there are N sboxes and each sbox is made by shuffling a 256
element array.
In a conventional cipher, you would have, each of the N bytes gets one
byte of keyschedule added, and is then substituted through fixed sbox,
and repeat the add-substitute step a few times.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?= <[EMAIL PROTECTED]>
Subject: Re: AES encryption speed vs decryption speed
Date: Tue, 20 Mar 2001 15:06:26 +0200
Understood.
-- Panu
------------------------------
** 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
******************************
