Cryptography-Digest Digest #179, Volume #12 Sat, 8 Jul 00 15:13:00 EDT
Contents:
Re: A new cipher........ (Simon Johnson)
Re: Concise Programming, Attn: Tom St. D & All (Rebus777)
Re: Porting Keys Between PGP, other Apps ("Ed Suominen")
Using CRC's to pre-process keys (Mack)
Re: A thought on OTPs (Mok-Kong Shen)
Proposal of some processor instructions for cryptographical applications (Mok-Kong
Shen)
Re: Proposal of some processor instructions for cryptographical applications
(Skipper Smith)
Re: Using CRC's to pre-process keys (Scott Nelson)
Re: Proposal of some processor instructions for cryptographical (Terje Mathisen)
Re: cray and time needed to attack (Jerry Coffin)
----------------------------------------------------------------------------
Subject: Re: A new cipher........
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sat, 08 Jul 2000 05:12:57 -0700
In your post this is just being Pedantic; its my first paper, it
likely to be incorrect. secondly, its _going_ to be weak,
there's no way that my first cipher is going to be strong,
third... the end user cannot use an existing algorithm, and only
has to be better than XOR's level security, (i'm sure my cipher
isn't that bad :p)
>3. The key-schedule is weak. There is a meet-in-the-middle
attack that
> uses a few known texts and the equivalent of 2^96 trial
encryptions.
> The weakness is that the first 8 rounds depend only on the
first 96
> bits of the key, and the last 8 rounds on only another 95
bits of key.
> This shows that the cipher has at best a 96-bit effective
keylength,
> shorter than what one would expect from a cipher with a 128-
bit key.
This however is more intresting....... I presume that the moral
of this story is to consider the key shedule more carefully and
insure all the bits of the key are used? I've been told that
using the same shift for all the rounds would allow related key
cryptanalysis to be successful, is this person sprinkling fairy
dust or is this true?
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Rebus777)
Subject: Re: Concise Programming, Attn: Tom St. D & All
Date: 08 Jul 2000 15:09:10 GMT
http://radsoft.net/bloatbusters/
>
>I was directed to this site in another News Group
>and as I read the pages I thought of some of you
>in sci.crypt that are ANTI_BLOATWARE.
>
>Have a look and help fight for the cause!
>
This site is a little hard to navigate.
Go to the bottom of each page and click on the more button. I quess it is just
one linear sequence.
-RSC
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp
Subject: Re: Porting Keys Between PGP, other Apps
Date: Sat, 8 Jul 2000 10:14:45 -0700
I posted this message a few days ago but didn't see it or any replies. My
apologies if this is a duplication. - Ed
=============================================
Originally, I wrote:
> > Can anyone shed light on this and why the PKCS #7 "thumbprint" is
> > different from the PGP "fingerprint" when its the same exact RSA
> > key?
>
To which Mark Woodring responded:
> I think that PKCS#7 hash is actually hashing some DER-encoding of
> the key, whereas PGP is doing something sensible and just hashing
> the key data. BER and DER encodings are part of the ASN.1
> braindamage which infests the PKCS standards.
And to which a person responded via email:
> SHA1 "Thumbprint"
> 91FE 6BC5 A1F8 6B0A 4B19 A035 B36B 136E 4C47 1944
> PGP "Fingerprint"
> 8EBF A10B A170 376D BCB6 649D 6143 D34A
>PKCS "thumbprint" is an SHA-1 hash of the key. PGP Fingerprint is
>an MD5 hash of the key. Different hash algorithms.
I don't think the difference is as simple as a SHA-1 vs. MD5, because
when I imported the PKCS certificate into Internet Explorer 5.0, I
got the correct 91FE... hash for SHA-1, but here's what IE5 told me
the MD5 hash is:
30A8 9E88 2DA1 6B43 8134 1125 7977 1827
I notice that PGP provides a 128 bit hash value while the SHA-1 hash
from PKCS has 160 bits. Does this mean that the email responder's
point is correct that PGP hashes the RSA key with MD5?
Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Using CRC's to pre-process keys
Date: 08 Jul 2000 17:27:00 GMT
Normally keys are preprocessed with MD5 or SHA-1
These tend to be a bit slow. And also a bit of
overkill if the cipher is secure.
I am proposing pre-processing with an appropriate
length CRC. ie. CRC-64, CRC-128 or CRC-256
depending on the required key. This effectively
reduces the key length of an ASCII key and
provides balanced output.
Another proposal involves a fixed non-linear table
substitiution as the first step. An 8-bit bijective table
with the properties that it have good avalanche
characteristics and at least some non-linearity.
The second step would be to run the output bytes
in a CRC-like manner. ie. the bytes are
processed so that each bit location within a byte
is CRCed with the corresponding bits in the other bytes.
For both of these methods the key is limited to 255 bytes.
The byte 0xff and the length are then prepended to the key
before processing. Then the final key is complemented.
For the second method the length would be substituted but
the byte 0xff would not.
A more technical description will be released if response
is positive.
Benefits of this method over a true hash are that it allows
mapping of weak keys to the true input and the speed
gained.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: Sat, 08 Jul 2000 19:52:52 +0200
Bryan Olson wrote:
> Mok-Kong Shen wrote:
>
> > "Douglas A. Gwyn" wrote:
> >
> > > Mok-Kong Shen wrote:
> > > > Also I asked sometime back whether there are good tests for
> > > > independence in practice but failed to get a concrete answer.
> > >
> > > I think you got answers, but just didn't like them.
> > > "Independence" of events is a theoretical notion used in models.
> > > It is not directly testable, but its consequences are testable
> > > with the usual statistical tools of hypothesis testing.
> >
> > If these 'consequences' that you mean (I am not aware, please name
> > these) could not be related mathematically to what I want to test,
> > namely independence, then they are of no use to me for my enquiry,
> > isn't it?
>
> Nonsense. The answer again: given two black-box sources
> we can in many cases reliably refute independence, but
> cannot reliably establish independence where it exists.
In many cases to refute the hypothesis of independence, of course,
namely when the two sources are found to be correlated. But we
want in the present context a test that is GENERALLY applicable
to investigate independence, in view of the troubling fact that zero
correlation does not imply independence.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Proposal of some processor instructions for cryptographical applications
Date: Sat, 08 Jul 2000 20:04:24 +0200
Transposition is one of the basic operations in cryptography.
However, it is in my view poorly supported currently by processor
instructions at the bit level at which all modern block ciphers
operate. For, while there are AND, OR and SHIFT/ROTATE
instructions to realize any arbitrary permutations of the bits
of a computer word, it can be very cumbersome and hence
inefficient to do so. Thus I like to suggest that future
processors will have an instruction to facilitate implementation
of encryption algorithms that employ arbitrary, eventually
dynamically determined, permutations of bits. Such an
instruction will naturally need two operands, one referencing
either a register or memory word and the other an arrary of
bytes/words that specify the target positions of the individual
bits. Since this very general instruction may be comparatively
costly in execution time, I think that the following two
special instructions could be desirable in addition:
(1) Swapping. This instruction needs an operand that specifies
the level at which the swapping is to be done. At the first
level, the word (register or memory) is divided into two halves
that are exchanged in positions. At the second level, the
swapping is done separately on each half of the word.
Analogously for the higher levels.
(2) Mirroring. This also has levels similar to swapping. At the
first level, the bits of the word referenced are exchanged by
mirroring about the central axis. At the second level, the
mirroring is done separately on each half of the word.
Analogously for the higher levels.
Another processor instruction that I think is desirable is
to obtain the parity of groups of bits (e.g. 4, 8, etc.) from
consecutive words in memory and accumulate these into a word.
This could be useful to so to say distill the entropy out of
a given bit sequence.
I should appreciate comments and suggestions of further
processor instructions that are useful for encryption purposes
and that are, hopefully, not inefficient for hardware
realizations.
Note. The concepts of the instructions described above are
herewith in the public domain. Their implementation and use,
in particular in cryptographical applications, are therefore
NOT patentable by any persons/firms.
M. K. Shen
================================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Skipper Smith)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Reply-To: [EMAIL PROTECTED]
Date: 8 Jul 2000 11:55:51 -0700
Have you looked at the AltiVec instructions contained in the MPC7400? You
can download the manual from:
www.mot.com/SPS/PowerPC/teksupport/teklibrary
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>Transposition is one of the basic operations in cryptography.
>However, it is in my view poorly supported currently by processor
>instructions at the bit level at which all modern block ciphers
>operate. For, while there are AND, OR and SHIFT/ROTATE
>instructions to realize any arbitrary permutations of the bits
>of a computer word, it can be very cumbersome and hence
>inefficient to do so. Thus I like to suggest that future
>processors will have an instruction to facilitate implementation
>of encryption algorithms that employ arbitrary, eventually
>dynamically determined, permutations of bits. Such an
>instruction will naturally need two operands, one referencing
>either a register or memory word and the other an arrary of
>bytes/words that specify the target positions of the individual
>bits. Since this very general instruction may be comparatively
>costly in execution time, I think that the following two
>special instructions could be desirable in addition:
>
>(1) Swapping. This instruction needs an operand that specifies
>the level at which the swapping is to be done. At the first
>level, the word (register or memory) is divided into two halves
>that are exchanged in positions. At the second level, the
>swapping is done separately on each half of the word.
>Analogously for the higher levels.
>
>(2) Mirroring. This also has levels similar to swapping. At the
>first level, the bits of the word referenced are exchanged by
>mirroring about the central axis. At the second level, the
>mirroring is done separately on each half of the word.
>Analogously for the higher levels.
>
>Another processor instruction that I think is desirable is
>to obtain the parity of groups of bits (e.g. 4, 8, etc.) from
>consecutive words in memory and accumulate these into a word.
>This could be useful to so to say distill the entropy out of
>a given bit sequence.
>
>I should appreciate comments and suggestions of further
>processor instructions that are useful for encryption purposes
>and that are, hopefully, not inefficient for hardware
>realizations.
>
>Note. The concepts of the instructions described above are
>herewith in the public domain. Their implementation and use,
>in particular in cryptographical applications, are therefore
>NOT patentable by any persons/firms.
>
>M. K. Shen
>--------------------------------
>http://home.t-online.de/home/mok-kong.shen
>
--
Skipper Smith Helpful Knowledge Consulting
Worldwide Microprocessor Architecture Training
PowerPC, ColdFire, 68K, CPU32 Hardware and Software
/* Remove no-spam. from the reply address to send mail directly */
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Using CRC's to pre-process keys
Reply-To: [EMAIL PROTECTED]
Date: Sat, 08 Jul 2000 18:57:51 GMT
On 08 Jul 2000 17:27:00 GMT, [EMAIL PROTECTED] (Mack) wrote:
>Normally keys are preprocessed with MD5 or SHA-1
>These tend to be a bit slow. And also a bit of
>overkill if the cipher is secure.
>
Speed is rarely an issue, but another problem
with secure hashes is they aren't easily extensible
to larger bit sizes. (It can be done, but it's
not obvious how to do it.) They're also not
guaranteed to fill the key space completely.
I.e. the SHA-1 hash of a 128 bit key isn't likely
to contain the full 128 bits, due to collisions.
A 128 bit CRC of a 128 bit key _is_ guaranteed to
have the same entropy.
>I am proposing pre-processing with an appropriate
>length CRC. ie. CRC-64, CRC-128 or CRC-256
>depending on the required key. This effectively
>reduces the key length of an ASCII key and
>provides balanced output.
>
Another advantage would be well defined results
when padding or shortening keys.
I.e. it would make absolutely clear, the exact method
used to turn a 7 byte key into a 128 bit key,
and how to shorten a 38 byte pass phrase.
I'm somewhat biased in favor of CRC over other methods,
but any consistent method of mapping key space which:
1.) Preserved all the entropy when expanding keys,
2.) Preserved as much entropy as possible when reducing them, and
3.) Is in the public domain.
would be an improvement over the current situation, IMO.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Sat, 08 Jul 2000 20:56:55 +0200
Mok-Kong Shen wrote:
>
> Transposition is one of the basic operations in cryptography.
> However, it is in my view poorly supported currently by processor
> instructions at the bit level at which all modern block ciphers
> operate. For, while there are AND, OR and SHIFT/ROTATE
> instructions to realize any arbitrary permutations of the bits
> of a computer word, it can be very cumbersome and hence
> inefficient to do so. Thus I like to suggest that future
> processors will have an instruction to facilitate implementation
> of encryption algorithms that employ arbitrary, eventually
> dynamically determined, permutations of bits. Such an
> instruction will naturally need two operands, one referencing
> either a register or memory word and the other an arrary of
> bytes/words that specify the target positions of the individual
> bits. Since this very general instruction may be comparatively
> costly in execution time, I think that the following two
> special instructions could be desirable in addition:
Since future crypto algorithms will work with a minimum block size of
128 bits, this instruction would at the very minimum be capable of
working with half that size, i.e. 64-bit registers. A generalized
bit-shuffle operation would then need something like 64 * 6 = 384 bits
of shuffle index data. (This could theoretically be limited to the
number of bits needed to encode 64!, but I would not like to try to
dynamically split this at runtime. :-()
As the regulars here (or Deja) can confirm, I'd love to have an opcode
like this, but I really don't see it as very likely. This is an awful
lot of hw to dedicate to a very specialized task, unless you want to use
the same hw to implement a single-bit latency full mesh 64x64 switch
matrix.
More reasonable would be a way to combine a couple of
lower-level/smaller shuffle opcodes, the Motorola Altivec has afaik got
the most useful version of this today.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Sat, 8 Jul 2000 13:00:35 -0600
In article <mx295.53$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> You may be surprised at the power afforded the everyday PC user by modern
> processors especially clustered processors. The commercial microprocessor
> has leapfrogged the supercomputer for certain types of calculations.
> Comparing computing power per dollar available from overclocked Pentiums or
> even Celerons with that of a Cray is pretty eye opening. Old S. Cray would
> have given his left gonad to science to be able to clock his processors at
> 1.6 GHz and run a large cache ram at half that speed with dual pipelined
> Harvard architecture, and cluster the processors with 10 Ghz fiber optics
> etc., etc.
Before he died, Seymour had built three Cray 3's, which were clocked
at 1 GHz. After CCI went bankrupt, Seymour started up a company
called SCI, but he was killed before they actually had a functioning
product. Given that the Cray 3's are over 5 years old, there's
little question that he could have built substantially faster
hardware by now if he'd had a chance.
I doubt he'd have been as excited as you think about clustering them
though: Seymour was _never_ an advocate of multiprocessor machines.
He (obviously) liked vector processing, but not arrays of processors
or anything along that line. I doubt it's a coincidence that Seymour
left Cray Research to become an independent consultant about the time
Cray Research decided to do their first multiprocessor machines.
If you want an advocate of highly parallel processing from roughly
the same era, you'd be looking for a guy named Chris Brandin, who ran
a substantially less famous company called BOS computers. There
were, of course, quite a few other companies that built massively
parallel machines (e.g. Thinking Machines) but TTBOMK, BOS was about
the only one that ever made any money. Oddly enough Chris and
Seymour lived only a few miles apart for quite a while. CCI and SCI
were based in Colorado Springs, CO, which happens to be the same
place Chris moved after selling BOS.
Despite being overshadowed while he ran BOS, Chris might be getting
the last laugh though: SGI recently sold the Cray product line to a
company named Tera Computing whose motto is something like "Beyond
massive parallelism." Between the (highly parallel) Cray T3 series,
and now having his name sold to Tera Computers, I suspect Seymour is
spinning in his grave.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
** 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
******************************
