Cryptography-Digest Digest #770, Volume #11 Sun, 14 May 00 12:13:01 EDT
Contents:
Re: Encryption of graphics by transposition (Tom St Denis)
AES on the AVR-RISC cpus? (Tom St Denis)
Re: security ([EMAIL PROTECTED])
Double Cypher ([EMAIL PROTECTED])
Re: security (Tom St Denis)
Notes on the "Vortex" block cipher (Tom St Denis)
Re: About Hardware RNG ("Steve and Darla Wells")
Re: Notes on the "Vortex" block cipher (Boris Kazak)
The hardware RNG you might already have... ("Steve and Darla Wells")
AES Comment: the Hitachi patent (Bruce Schneier)
Re: How does one test an encryption algorithm? (Bruce Schneier)
Re: The hardware RNG you might already have... (Roger Schlafly)
Re: About Hardware RNG (Tom St Denis)
Re: Notes on the "Vortex" block cipher (Tom St Denis)
Re: S-BOX Construction Tutorial? (Tom St Denis)
Re: Notes on the "Vortex" block cipher ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encryption of graphics by transposition
Date: Sun, 14 May 2000 13:26:21 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Bailey) wrote:
> Are the usual encryption techniques, eg pgp, feistel ciphers, DES, etc
> really suitable for encrypting graphics, eg gif files, pgp files, etc?
> A more straightforward approach than using these substitution based
> ciphers would be remapping the location of pixels within the image,
> using any of several techniques which guarantee one to one mapping
> consistency.
> An example of raster transposition can be seen at
> http://www.frontiernet.net/~jmb184/interests/fractals/Rasterless/
Try encrypting a completely white picture.
> Perhaps the answer is as simple as the possibility that once a strong
> encryption process has been used for pixels value, there is no point
> in using raster transposition as well.
> My questions:
> 1) Are graphics encrypted with conventional encryption vulnerable to
> attacks different from (and possibly easier than) text encrypted with
> the same techniques?
No, typically we don't view attacking a cipher from the type of input
you give it. Linear cryptanalysis of DES could work if the input were
ASCII, MP3 audio, etc...
> 2) If raster location transposition was used would graphic encryption
> be stronger?
Probably not.
> What do you think?
A really non-conventional idea that has no clear advantage over plain
and simple symmetric encryption? Sure why not.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: AES on the AVR-RISC cpus?
Date: Sun, 14 May 2000 14:00:01 GMT
Has anyone tried todo any of the last five AES ciphers on the AVR style
cpus? They come in a variety of packages (from 8-pin tiny cpus to huge
cpus), moderately we are talking about the AVR 2313 which is the all-
around CPU (128 bytes of sram, 2kb of flash eprom). These cpus get MHZ
= MIPS performance so ideally any well-tuned AES cipher should zoom on
it.
The only big problem is the lack of SRAM... Some of the other AVR's
have upto 4kb of SRAM but they are bigger cpus (draw a bit more
current, not much mind you) and are harder for hobbiest to use...
Do any of the AES ciphers work with only say 64 bytes of sram?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: security
Date: Sun, 14 May 2000 14:02:24 GMT
OK, I am learning here so please forgive my lack of perhaps basic
knowledge.
What is the definition of "block cypher" and "crytosystem"? What are
the differences as far as application goes?
Thank You,
WS
In article <[EMAIL PROTECTED]>,
dformosa@[202.7.69.25] wrote:
> On Sat, 13 May 2000 17:41:17 GMT, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>
> >There seems to be two products. PGP and Blowfish. Can anybody tell
me
> >the difference between the two, which oneprovides more security as
far
> >as some one being able to break the code and read my stuff, I mean
real
> >smart people.
>
> Blowfish is a block cypher, it has a good reputation. PGP is a
crytosystem
> it has also got a good reputation. There not realy compartatable as
> each proforms a diffrent role.
>
> PGP makes use of diffrent cyphers.
>
> --
> Please excuse my spelling as I suffer from agraphia. See
> http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
> Interested in drawing platypie for money? Email me.
> Crack my Hash win$200
http://dformosa.zeta.org.au/~dformosa/PlatyMAC.txt
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Double Cypher
Date: Sun, 14 May 2000 14:13:14 GMT
It is tough to be a newbie.
Would it be possible to cypher a file using say, Blowfish, and then
cypher the the newly created cyphered file using another s/w, say PGP?
What will be the consequences? Any pluses or any negatives?
In article <8fk43r$5ic$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I have recently come to figure that I really need to have my data out
> of the hands of people who do not need to see my stuff.
>
> There seems to be two products. PGP and Blowfish. Can anybody tell
me
> the difference between the two, which oneprovides more security as far
> as some one being able to break the code and read my stuff, I mean
real
> smart people.
>
> Any suggestion is appreciated.
>
> WS
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: security
Date: Sun, 14 May 2000 14:30:15 GMT
In article <8fmbla$e41$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> OK, I am learning here so please forgive my lack of perhaps basic
> knowledge.
>
> What is the definition of "block cypher" and "crytosystem"? What are
> the differences as far as application goes?
>
> Thank You,
> WS
A block cipher is just an algorithm were some information (call it P)
goes into the algorithm as an argument. The algorithm returns some
information (call it C).
The input (P) is called Plaintext, and the output (C) is called
Ciphertext. There is a n-bit key (K) that controls the mappings of P
to C. Obviously the larger the key, the more mappings, and the longer
it takes to brute force (if brute force is the fastest way).
You can draw it like
Ek(P) -> C
Which would read 'The encryption of P with key k transforms into
ciphertext C'. I would pick up Applied Crypto or HAC and read up more
on it.
A Cryptosystem is an application/device that makes use of these
algorithms (among other algorithms such as hashes, prngs and pk) to
provide some security. PGP for example lets the users send encrypted
messages/files and signed messages/files using various algorithms.
Technically PGP is not a cipher so it doesn't encrypt anything. It
just controls the ciphers that *do the work*.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 14:34:26 GMT
I noted in the F function there is a very simple compression of four 16
bit values given
F(a, b, c, d) = ((a ^ b) + c) ^ d -> a'
Then only a' is passed thru the sboxes.... Wouldn't it be possbible to
create a quadruple so that the input difference is fixed?
I think this compression is a point of attack... now only if the brains
in sci.crypt could play with that :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Steve and Darla Wells" <[EMAIL PROTECTED]>
Subject: Re: About Hardware RNG
Date: Sun, 14 May 2000 07:57:43 -0700
Although such circuits generate entropy, they typically generate detectable
weaknesses through either interference coupling and/or bias with the
environment. Be sure to post process the result well.
---Steve
"Mike Rosing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > I was wondering (being spoiled as I am) does anyone have a bread-boarded
> > version of
> >
> > http://world.std.com/~wware/hw-rng.html
> >
> > Using either a 18v input or on-board 9v batt supply?
> >
> > That you can spare? I want to try it out, but I don't know how to read
> > the diagram properly (I know the basic symbols....).
>
> Not on me. But that's really an RF receiver, not a RNG. The "not
> connected"
> pin is an antenna. You want a source that's more secure, like a battery
> inside a shielded box. You also want the ability to balance the output.
> that circuit isn't tunable.
>
> Breadboards are expensive. See if you can find some stuff at Radio
> Shack
> (or get a real parts catalog like DigiKey). Hardware is fun, but just
> as
> time consuming as software :-)
>
> Patience, persistence, truth,
> Dr. mike
>
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 15:19:13 GMT
Tom St Denis wrote:
>
> I noted in the F function there is a very simple compression of four 16
> bit values given
>
> F(a, b, c, d) = ((a ^ b) + c) ^ d -> a'
>
> Then only a' is passed thru the sboxes.... Wouldn't it be possbible to
> create a quadruple so that the input difference is fixed?
>
> I think this compression is a point of attack... now only if the brains
> in sci.crypt could play with that :)
=====================
Unlikely - this sequence of ADD and XOR is already used in the
F function of BLOWFISH. Alternating different noncommutable arithmetic
operations discourages attacks based on differences and transpositions.
Best wishes BNK
======================
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Steve and Darla Wells" <[EMAIL PROTECTED]>
Subject: The hardware RNG you might already have...
Date: Sun, 14 May 2000 08:27:01 -0700
There is quite a bit of discussion of bread boarding hardware RNGs. You
might already have one.
Check out http://developer.intel.com/design/security/rng/rng_v3.htm
A good review can be found at http://www.cryptography.com/intelRNG.pdf
---Steve
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: AES Comment: the Hitachi patent
Date: Sun, 14 May 2000 15:33:26 GMT
I just sent this comment to NIST:
Bruce
********************************************************
Hitachi has two U.S. patents, numbers 4,982,429 and 5,103,479, each of
which is purported to cover "any" encryption system using rotations.
These patents were filed in 1988. All of the five AES candidates use
some kind of rotation, including Rijndael's ShiftRow operation.
However, for what it's worth, it should be noted that Twofish can be
implemented as a "straight Feistel cipher plus a final permutation,
with rotations applied only within the round function, not in the
Feistel XOR path.
The authors of Twofish were unaware of these patents until recently,
but the notion that such a broad claim could be valid seems quite
ludicrous. he following well-known pieces of prior art would seem to
at least dramatically limit the scope (if not completely invalidate)
any such claims.
1) FEAL (1987) uses a rotation in its round function.
2) Madryga (1984) uses a variable rotation in its round function.
3) DES (1977) uses a rotation in each round of its key schedule.
4) DES (1977) uses a bit permutation (of which rotations are a
special case) in every round.
5) GOST (1989) applies a bit permutation (that is a rotation) in
each round after performing its S-box lookup
6) The very words "rotor" and encryption have been linked for a long
time (e.g., the Caesar cipher, and Enigma)
The concept of rotation in encryption was clearly neither novel nor
unobvious at time these patents were filed. The fact is that EVERY
microprocessor opcode has been considered for use in encryption, with
rotation being just one example.
This particular example is a counter to the "IP attack" argument
espoused by some as a reason to select multiple AES algorithms instead
of a single one. It is most likely that IP attacks, if any, will be
based on very broad and ambiguous claims (like those of Hitachi) that
the patent holder attempts to apply to all encryption systems.
Niels Ferguson
Bruce Schneier
David Wagner
Doug Whiting
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: How does one test an encryption algorithm?
Date: Sun, 14 May 2000 15:39:25 GMT
On Thu, 11 May 2000 00:37:29 GMT, [EMAIL PROTECTED] wrote:
>I have an dynamic encryption algorithm and it needs to be tested. Is
>there a newgroup or a group of freelance hackers :-) or some place
>where I could test by hiring services.
>
>All I want to know is that if my algorithm is tough to crack.
>
>How does one estimate the confidence factor of an encryption algorithm?
>Are there any metrics defined?
See:
http://www.counterpane.com/crypto-gram-9810.html#cipherdesign
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: The hardware RNG you might already have...
Date: Sun, 14 May 2000 08:44:31 -0700
Steve and Darla Wells wrote:
> There is quite a bit of discussion of bread boarding hardware RNGs. You
> might already have one.
>
> Check out http://developer.intel.com/design/security/rng/rng_v3.htm
>
> A good review can be found at http://www.cryptography.com/intelRNG.pdf
Or you may not. According to Intel, there is no reliable way
to detect it, or for applications to use it in a multitasking
situation. Intel has announced that it is abandoning the
accompanying serial number, so it is not clear Intel will
stick with this either.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: About Hardware RNG
Date: Sun, 14 May 2000 15:47:42 GMT
In article <kezT4.357$[EMAIL PROTECTED]>,
"Steve and Darla Wells" <[EMAIL PROTECTED]> wrote:
> Although such circuits generate entropy, they typically generate
detectable
> weaknesses through either interference coupling and/or bias with the
> environment. Be sure to post process the result well.
The device I am building will feed the output to a data pin on a AVR
2313, which will hash it (using MD2). I currently have it set to hash
256 bytes downto 16 bytes before outputting.
The device will be the size of a wallet and have a simple RS-232
interface. A tiny TTY host in the AVR will allow the users to
request 'x' amount of bytes, afterwhich the device will go to sleep
mode.
I hope to build a prototype this week (I want to make an AVR eval
board, and just stick the RNG device on it).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 15:45:04 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
>
> Tom St Denis wrote:
> >
> > I noted in the F function there is a very simple compression of
four 16
> > bit values given
> >
> > F(a, b, c, d) = ((a ^ b) + c) ^ d -> a'
> >
> > Then only a' is passed thru the sboxes.... Wouldn't it be possbible
to
> > create a quadruple so that the input difference is fixed?
> >
> > I think this compression is a point of attack... now only if the
brains
> > in sci.crypt could play with that :)
> ---------------------
> Unlikely - this sequence of ADD and XOR is already used in the
> F function of BLOWFISH. Alternating different noncommutable
arithmetic
> operations discourages attacks based on differences and
transpositions.
Yeah but in blowfish all of the input goes thru the sboxes. So you
can't just say "Blowfish is similar so my cipher must be secure too".
What I am saying is you compress (a, b, c, d) downto (a') and only send
a' thru the sboxes.
I think you can attack the compression function to controll the sbox
usage.
I am not saying it's broken, I am just pointing out an avenue of attack.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Sun, 14 May 2000 15:53:28 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Sat, 13 May 2000 14:49:10 -0700, in
> <8fjm8v$nqr$[EMAIL PROTECTED]>, in sci.crypt "Simon Johnson"
> <[EMAIL PROTECTED]> wrote:
>
> >Does any one have a PDF or HTML S-BOX construction tutorial?
> >If So please, leave a post with the URL as a reply to this message
thanxs.
>
> "S-boxes" are used in different ways in different ciphers, making
> different things more or less important. Any particular construction
> approach probably will be oriented toward a particular design, and the
> approach you need should be oriented toward your particular needs.
Some overall characteristics such as linearness and differential xor-
pair tables are universally important. If your sbox is a linear
mapping of Fn -> Fm then it's kinda useless isn't it?
> Typically, a modern S-box has an even binary power number of elements
> (e.g., 2**4 or 16, 2**8 or 256, etc.). There is one element of each
> possible value and these are permuted or shuffled. Up to this point,
> all we need to know is how to count and how to shuffle.
>
> Some designs use "small" (e.g., "4-bit") S-boxes, but such small boxes
> are often weak, and so should be tested before being used. There are
> various tests including diffusion, Boolean function nonlinearity,
> etc., with at least one new test found for every new attack on S-box
> structure. An alternative is to use "large" ("8-bit" or larger)
> S-boxes, but that is a cipher design decision.
Yeah I agree with the less-non-linearness of small sboxes, but can you
point me to an attack on Serpent that relies on the sboxes?
> DES-style ciphers often have a fixed set of boxes; that means
> opponents will know the complete structure, thus making their attacks
> that much easier. An alternative is to key-select each box "at
> random" from among all possible permutations, but that is another
> cipher design decision.
Random sboxes are only secure if they are large (aka Blowfish style
8x32). Random 4x4 sboxes are often closer to linear then ideal...
Question: has anyone tried a 128-bit blowfish by using eight 8x32
sboxes? Seems to me it would require only 8kb of ram which isn't
prohibitive on desktop computers...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 15:52:08 GMT
In article <8fmdhi$ftu$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I noted in the F function there is a very simple compression of four
16
> bit values given
>
> F(a, b, c, d) = ((a ^ b) + c) ^ d -> a'
>
> Then only a' is passed thru the sboxes.... Wouldn't it be possbible to
> create a quadruple so that the input difference is fixed?
....
>
> Tom
sci.crypt,
See the Vortex cipher at
http://www.wizard.net/~echo/crypto-contest.html
Tom,
Good point. A fixed a' can easily be created. Here is the actual
transform, note the + and ^ have been swapped from yours. The letters
are 16 bit values here so a carry can slighty affect the results.
F(a, b, c, d) = S[((a + b) ^ c) + d] -> a'
F(a', b, c, d) = S[((a' + b) ^ c) + d] -> b'
F(a', b', c, d) = S[((a' + b') ^ c) + d] -> c'
F(a', b,' c', d) = S[((a' + b') ^ c') + d] -> d'
A least two of the values must be changed to create an equal a'.
For instance, (a,b,c,d) and (a,b,d,c) can give an equal a',b' and c'.
The d' will be (a',b',c',d) and (a',b',c',c) which will be unequal for
c!=d. Even one bit of difference will result in one byte of diffence
in d'.
Here are the relevant bits of code from the reference addition round
function.
MixWords(&cipherText); // the a+b^c+d transfrom
PHT(&cipherText); // a' = a+b; b' = 2*a+b;
Permute(&cipherText); // reorder the bytes
PHT(&cipherText);
Permute(&cipherText);
PHT(&cipherText);
The series of PHT and Permute is designed to make all eight bytes
depend on each other. So a one byte difference from the MixWords will
result in 8 different output bytes, in general.
In short, I saw this problem during design and believe that linear
transform erases it.
--Matt
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
