Cryptography-Digest Digest #867, Volume #11 Fri, 26 May 00 22:13:01 EDT
Contents:
Re: Another sci.crypt Cipher (David A. Wagner)
Re: Another sci.crypt Cipher (David A. Wagner)
Test - Please ignore! (Erick Stevenson)
Re: NSA hardware evaluation of AES finalists (Ken Lamquist)
Re: Another sci.crypt Cipher (tomstd)
Re: Another sci.crypt Cipher (tomstd)
Re: Is OTP unbreakable? (Guy Macon)
Comments requested: One way function blast() (Andru Luvisi)
Re: Is OTP unbreakable? (Tim Tyler)
Re: Retail distributors of DES chips? (zapzing)
Re: Retail distributors of DES chips? (zapzing)
Re: bamburismus (John Savard)
Re: Retail distributors of DES chips? (zapzing)
Free Software (George Peters)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Another sci.crypt Cipher
Date: 26 May 2000 16:07:58 -0700
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> The char is (00010000) -> (00000000) -> (00030000) -> ... right?
>
> The best learning "thing" you could do for me right now is
> explain how you found that differential. I have been scratching
> my head all day about it.
In general, if A->B and B->A are both good characteristics
for the F function, then you get a 3-round characteristic
for the cipher, like this: (A,0) -> (0,A) -> (A,B) -> (B,0).
Similarly (B,0) -> (0,B) -> (B,A) -> (A,0). So, this gives
a 6-round iterative characteristic with 4 active rounds.
This is a very useful pattern, since it has the potential
to apply even if the F function is bijective.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Another sci.crypt Cipher
Date: 26 May 2000 16:17:01 -0700
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> In article <8gm9j1$gm2$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (David A. Wagner) wrote:
> >There is also a larger class of 2^96 weak keys [...]
>
> Wouldn't xoring a round counter with the key in each round
> prevent these attacks?
Yes, as far as I know. That's the natural thing to try, anyway.
------------------------------
From: Erick Stevenson <[EMAIL PROTECTED]>
Subject: Test - Please ignore!
Date: Fri, 26 May 2000 23:20:59 GMT
Thanks anyway,
Erick
------------------------------
From: [EMAIL PROTECTED] (Ken Lamquist)
Subject: Re: NSA hardware evaluation of AES finalists
Date: Fri, 26 May 2000 23:19:16 GMT
David A. Wagner asked:
> Is this the right metric? If you have extra area, won't you typically
> be able to add extra encryption units? I don't have enough experience to
> know whether you can, but if you can indeed add extra encryption engines,
> Rijndael's lead here will evaporate, so it seems like a rather important
> question to ask before relying on those numbers too heavily.
The answer depends on the application. Not being a hardware designer,
I'm not in a good position to comment on what is typical. I consider
both speed and throughput per unit area to be useful metrics. Here
are some reasons why I consider speed important:
First, it is possible to come up with applications where latency is
critical. Consider a high security computer system in which all data
in main memory is encrypted. If 64 byte cache lines are used, then
loading a cache line from memory requires four decryptions which can
be performed in parallel to increase performance. However, the most
critical issue for the performance of the system is likely to be the
time required to provide the CPU with the word of data specified in
the load instruction, and parallel decryption doesn't help with that.
This is a rather specialized application, but the AES is supposed to
be a general purpose encryption algorithm, not an algorithm targeted
for a few common applications.
Second, with CBC mode encryption, parallel encryption is only possible
if you are encrypting multiple data streams at once. You can get the
advantages of CBC mode, without the limitation on parallelism, by
xor-ing the data stream with the output of a pseudo-random number
generator. The disadvantages of doing this are that it imposes
additional cost, and it is not standardized.
Third, applications that allow parallel encryption may not allow
*unlimited* parallel encryption. Integrated circuit density keeps
on increasing, so unless the limit on parallelism is very large, we
will hit the limit during the lifetime of the AES.
Fourth, software performance comparisons of the AES candidates have
concentrated on speed rather than throughput. I read all of the
first round comments and do not recall anyone suggesting that NIST
should take software throughput into consideration at all. Hardware
designers are probably on average more open to the idea of parallelism
than software designers because hardware circuits normally contain
parallelism, and because the benefits of parallelism in hardware are
greater than the benefits of parallel implementations in software.
So you could argue that the software evaluations have used the wrong
metric or that hardware is enough different from software that a
different metric is appropriate.
If the AES were targeted at a specific application, we could determine
the requirements of that application and evaluate the AES candidates
against those requirements. But the AES is intended to be useful for
a wide variety of applications, including applications that have not
yet been invented. Therefore, it makes sense to place the most
emphasis on those measures of performance that make the fewest
assumptions about the nature of the application. Making encryption
faster improves the performance of all applications. Making the
encryption take less chip area so that more encryption circuits
can be placed on a single chip only improves the performance of
applications that can benefit from performing more encryptions in
parallel. Therefore, speed is a more widely applicable measure of
performance.
Kenneth Almquist
------------------------------
Subject: Re: Another sci.crypt Cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 26 May 2000 16:38:33 -0700
In article <8gn0ld$hae$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>tomstd <[EMAIL PROTECTED]> wrote:
>> In article <8gm9j1$gm2$[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (David A. Wagner) wrote:
>> >There is also a larger class of 2^96 weak keys [...]
>>
>> Wouldn't xoring a round counter with the key in each round
>> prevent these attacks?
>
>Yes, as far as I know. That's the natural thing to try, anyway.
Hmm well I think I am just re-inventing CAST anyways. It's a
nice cipher, and it was fun exploring the bit permutation.
What I would really like to know is how he found that
differential.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Another sci.crypt Cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 26 May 2000 16:41:28 -0700
In article <8gn04e$h9e$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>tomstd <[EMAIL PROTECTED]> wrote:
>> The char is (00010000) -> (00000000) -> (00030000) -> ...
right?
>>
>> The best learning "thing" you could do for me right now is
>> explain how you found that differential. I have been
scratching
>> my head all day about it.
>
>In general, if A->B and B->A are both good characteristics
>for the F function, then you get a 3-round characteristic
>for the cipher, like this: (A,0) -> (0,A) -> (A,B) -> (B,0).
>Similarly (B,0) -> (0,B) -> (B,A) -> (A,0). So, this gives
>a 6-round iterative characteristic with 4 active rounds.
>This is a very useful pattern, since it has the potential
>to apply even if the F function is bijective.
This is a flaw of the bit permutation or my F function in
general?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Is OTP unbreakable?
Date: 26 May 2000 20:17:36 EDT
In article <8gmi2g$9mv$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>
>In article <8gmfq9$ol4$[EMAIL PROTECTED]> Mickey McInnis,
>[EMAIL PROTECTED] writes:
>>One way to exploit this is:
>>
>>1) Somehow determine the cleartext for one message or part of a
>> message . (dumpster diving, find a note that was sent to many
>> correspondents, one of whom you've corrupted, etc.)
>>
>>2) Intercept the ciphertext.
>>
>>3) Determine the pad from the cleartext/ciphertext pair.
>>
>>4) Now you can encrypt a message of the same length as this one
>> cleartext and send it to the recipient and it will look as
>> though it came from the "authorized" sender. If you have a
>> partial message, you can change that part of the message.
>>
>I'm a little confused about your reasoning for item 4. You've recovered
>plaintext and intercepted the corresponding ciphertext. From these, you
>have recovered the keystream used for that message.
>
>Since the OTP security is based on never using the same portion of
>keystream twice (hence, "One Time"), how would your new message pass
>muster if it uses the previously used keystream? Are you assuming that
>the ciphertext you intercepted did not reach the receiver?
He has to be assuming that, otherwise it doesn't work.
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Comments requested: One way function blast()
Date: 26 May 2000 17:58:00 -0700
What follows is a 32 bit -> 32 bit one way function I've been working
on. It is based upon a block cipher with a 4 bit key and a 2 bit
block, which is run Davies-Meyer style to form a hash function. Two
bits of the 32 bit value are modified each time.
Regarding the 2 bit block cipher:
There are 24 possible permutations of the numbers 0 through 3.
Deciding that having some permutations be unreachable is better than
having some be more likely than others, I opted to use a 4 bit key to
pick from among 16 combinations, rather than a 5 bit key to pick from
among 24. I chose to discard the permutations which were rotations of
{ 0, 1, 2, 3 } and { 3, 2, 1, 0}. The remaining permutations have the
nice property that given a random key, every output is equally likely
for every input.
Here is the source code for blast(). Comments requested:
/* A table driven cryptosystem with a 4 bit key and a 2 bit block size. */
/* There are 24 different permutations of the values 0-3. Below are
all but the 8 which are rotations of { 0, 1, 2, 3 } or { 3, 2, 1, 0 }. */
/* E_k(p) = s[k][p] */
unsigned char s[16][4] = {
{ 0, 1, 3, 2 },
{ 0, 2, 1, 3 },
{ 0, 3, 1, 2 },
{ 0, 2, 3, 1 },
{ 1, 0, 2, 3 },
{ 2, 0, 1, 3 },
{ 2, 0, 3, 1 },
{ 3, 0, 2, 1 },
{ 1, 2, 0, 3 },
{ 1, 3, 0, 2 },
{ 3, 1, 0, 2 },
{ 3, 2, 0, 1 },
{ 1, 3, 2, 0 },
{ 2, 1, 3, 0 },
{ 3, 1, 2, 0 },
{ 2, 3, 1, 0 }
};
/* 32 bit -> 32 bit one way function (hopefully) */
unsigned int blast(unsigned int data) {
unsigned char a, i, j, k;
for(i = 0; i < 2; i++)
for(j = 0; j < 16; j++) {
/* Davies-Meyer: The encryption table above is used to make a */
/* hash compression function h_i = h_{i-1} XOR E_{m_i}(h_{i-1}) */
for(a = (j % 4), k = 0; k < 8; k++)
a ^= s[(data >> 4*k) & 0xf][a];
data ^= (((unsigned int)a) << 2*j);
}
return data;
}
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 27 May 2000 00:33:08 GMT
Greg <[EMAIL PROTECTED]> wrote:
:> The OTP does not offer any authentication.
: How rediculous. OTP offers the same level of authentication as
: most other private keys in a public key cryptosystem. If you have
: the key, then you can sign the document. That is all authentication
: means. [...]
With conventional symmetric systems, attackers can't use known plaintext
to forge messages - even if no digital signature technique has been
employed.
They offer beter authentication than an OTP in this sense - if you
receive an encrypted, unsigned document, you can be more certain that
it did not come from an attacker than you would be able to if it had
been encrypted using an OTP - since the attack on the OTP is more simple
and obvious, than an attack on the symmetric cypher is likely to be.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Retail distributors of DES chips?
Date: Sat, 27 May 2000 01:06:36 GMT
In article <8gfqfb$hfa$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> In article <8gfov7$lt4$[EMAIL PROTECTED]>, zapzing
<[EMAIL PROTECTED]> wrote:
> >> At anyrate any joe-blow DES chip that conforms to the DES
> >> standard when testing with random keys/plaintext is most likely
> >> a real chip, and not some cloak.
> >
> >That's what I am hoping for. There is also the possibility of feeding
> >the chip "fake" plaintext and keys so it wouldn't know what
> >information to leak out even if it did have the opportunity to leak
> >some information.
> >
> >If you know about a retail source of inexpensive DES chips, please
> >let me know, thanks.
>
> I'm still extremely confused about what you want a DES chip for,
> if it's not for a high-performance hardware encryption application.
>
> If you can describe more concretely what you want to use the chip for,
> I might be able to make useful suggestions.
>
> For example, if you want a tamper resistant hardware DES
implementation
> with encapsulated keys try the Java buttons I mentioned in another
> article. They're fairly slow, but very secure.
>
Yup. tamper resistance is the point.
I can't find your stuff about "java buttons"
but that doesn't mean much since deja has
been so flakey lately.
But how could something written in Java be
considered a hardware solution? Is this
a microprocessor application?
--
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: zapzing <[EMAIL PROTECTED]>
Subject: Re: Retail distributors of DES chips?
Date: Sat, 27 May 2000 01:14:14 GMT
In article <8gf9eu$9sb$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> In article <8gf5j2$8ui$[EMAIL PROTECTED]>, zapzing
<[EMAIL PROTECTED]> wrote:
> >Well, One of the things I have been considering is the possibility of
> >malicious software. That's why I was considering using a chip. That
> >way there is absolutely no possibility that anythink will be placed
> >in any subliminal channels.
>
> DES is a block cipher, a one-to-one, invertible mapping between
plaintext
> and ciphertext. It can't and doesn't have subliminal channels. Maybe
> you're thinking of DSA. For DSA, a hardware implementation would be
> *more* susceptible to subliminal channels than a software
implementation,
> assuming you had source code for the software that you could inspect.
>
Not the DES algorithm itself. It doesn't have
any subliminal channels. But if I go with
software encryption then how can I be certain that
DES was actually used, and not some less
powerful algorithm?
> >I figure there must be some old chips lying around. If I can't find a
> >reasonably priced tamperproof chip, I may just rig up my own
> >tamperproof container.
>
> If you're looking for tamper resistant key management, try a smart
> card ship or something like a Java iButton
> (http://www.ibutton.com/ibuttons/java.html). These are not what I'd
> call a DES chip in that they are normally small microprocessors that
> implement DES in firmware rather than hardware. But they are
> inexpensive and reasonably secure.
>
Oh, one of those "firmware" things .
That's what I thought. That is certainly
another possibility I will be considering.
--
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: [EMAIL PROTECTED] (John Savard)
Subject: Re: bamburismus
Date: Sat, 27 May 2000 01:17:35 GMT
On Fri, 26 May 2000 14:13:00 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>Which part?
That, at (presumably) a specific date in the past, the NSA definitely
could not crack 3DES.
That, at a specific date in the past, the NSA was in posession of
theoretical results relevant to the cracking of 3DES - from which, its
capability or otherwise to crack 3DES in the present day moves from
the realm of a _possibility_ to that of (however vaguely estimated) a
_probability_.
Those were the things that I would believe to be _considered_
injudicious by those who are concerned with maintaining security. As
to the question of _genuine_ damage to national security, however, I
will admit to being unqualified to comment.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Retail distributors of DES chips?
Date: Sat, 27 May 2000 01:32:02 GMT
In article <8gm6b7$eqv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jonathan Thornburg) wrote:
Yes that was exactly the sort of thing I was
worried about. And there are two things
I think are essential to overcome this sort of
problem: 1) trial decryptions should be done
*before* the message is transmitted or
recorded in permanent form. 2) Split the
message up into two secrets by xoring with
a random bit stream. This random bit stream,
and the xoring hardware, should be made out
of discrete components.
Also, other tricks should be used such
as pre- and post-permutations that are
done "in hardware" by just switching the
wires around, etc. Use several stages
of encryption.
Your trial decryption is in software on
a different machine, and the source is
highly obfuscated.
--
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: George Peters <[EMAIL PROTECTED]>
Subject: Free Software
Date: Sat, 27 May 2000 02:07:54 GMT
There is a suite of encryption products you should explore. There are
two file encryption systems, client email ftp and messenging
applications, and some source code. You can get it at
www.endecs.com/uenigma.exe. It's a self extracting exe and you simply
run setup.exe after extracting.
This was the product of a now defunct software company. Some of the
source code is in Visual Basic and it looks like Borland C++ for others.
Would enjoy your comments about the software...My computer gurus think
it's pretty good stuff!
George
------------------------------
** 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
******************************
