Cryptography-Digest Digest #210, Volume #12 Wed, 12 Jul 00 05:13:01 EDT
Contents:
Re: Crypto jokes? (potentially OT) (Steve Meyer)
Re: Proposal of some processor instructions for cryptographical applications (Greg)
Re: Base Encryption: Strongest Cypher ([EMAIL PROTECTED])
New Idea - Cipher on a Disk (Greg)
Re: Base Encryption: Strongest Cypher (S. T. L.)
Re: New Idea - Cipher on a Disk (David A Molnar)
Definition question (Ichinin)
Re: Base Encryption: Strongest Cypher (Steve Rush)
Re: RC4-- repetition length? (Runu Knips)
Re: blowfish & 8 byte blocks (Runu Knips)
Re: Proposal of some processor instructions for cryptographical applications (Jan
Vorbrueggen)
attack against CBC mode (Serge Vaudenay)
Re: Proposal of some processor instructions for cryptographical applications (Jan
Vorbrueggen)
SC also in inverse ? (Runu Knips)
Re: RC4-- repetition length? (Benjamin Goldberg)
Re: Proposal of some processor instructions for cryptographical applications ("Peter
L. Montgomery")
Re: Steganographic encryption system (John Hasler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Steve Meyer)
Subject: Re: Crypto jokes? (potentially OT)
Reply-To: [EMAIL PROTECTED]
Date: 12 Jul 2000 05:24:50 GMT
How about claim by BBC television producer that English spy ageny
discovered public key cryptography. Probably in joke that one must
attend IACR conference to appreciate.
/Steve
On Thu, 06 Jul 2000 11:41:36 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Does anyone know any crypto-related jokes or links to them?
>Or perhaps someone could come up with an ingenious answer to the
>question:
>
>How may cryptographer does it take to change a light bulb?
>
>Thanks in advance for any suggestions
>
>rot26
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Wed, 12 Jul 2000 05:07:33 GMT
> Finite field GF(2^8) and GF(2^16) multiplication (modulo some
> fixed irreducible polynomial) would be nice. May be also some
> other operations (x->x^-1, e.g.).
I agree, that support for finite fields would be a welcomed
enhancement to any general processor, but then it would not be
so general. In fact, the finite field processing must be kept
general, and that is hard enough. But then you want to take
up silicon as well. That would be a hard push for any chip
manufacture to justify given today's market. But perhaps soon
they will, given the improvements and other enhancements we
are seeing.
> Several AES finalists (Rijndael, Twofish, MARS) would accelerate
> considerably if the next block of four 32-bit memory references
> could be computed by one instruction:
>
> A:=table[(X>>0)&255 + C1*256]
> B:=table[(X>>8)&255 + C2*256]
> C:=table[(X>>16)&255 + C3*256]
> D:=table[(X>>24)&255 + C4*256]
It would be nice if there was a multi pipeline that worked
in such a way to provide similar action on a single instruction.
But if it is kept general enough, then you have setup, and that
overhead would have to be worth the size of the effort. For those
who want to encrypt an entire disk, the payoff would certainly
be there.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Base Encryption: Strongest Cypher
Date: Wed, 12 Jul 2000 05:30:05 GMT
[EMAIL PROTECTED] wrote:
> It is immune from plain-text-attacks because multiple algorithms
> can generate same plaintext. Multiple algorithms can generate
> same cyphertext. It is like saying how many ways are there to
> come up with 12345? (infinite: 12344+1, 12343+2, 1+1+1+12342, etc)
It's late here, but I strongly suspect the set of numbers that add up
to 12345 is finite. I mean, there certainly aren't any small integers
with inifnite amounts of numbers that add up to them, and I fail to
see why the same principle doesn't apply to five digit ones. ;)
> It is immune from brute-force-attacks. A lot of pepple on this
> forum simply do not understand this. Read the Garage Door example,
> then the Chinese Newspaper, then come back to me. It is exponentially
> expensive. Then when you come back to me, and STILL don't get it.
A problem with a solution in exponential time isn't impossible. It's
just difficult.
> 3) MORE secure as OTP.
This is extremely doubtful.
> Now, you can use plain text attack on that piece of paper on the One
> Time Pad. Can you do that on Base Encryption? NO.
I, for one, would be interested in hearing how a known plaintext
attack on a sheet off a one time pad worked. (Assuming you don't know
the entire plaintext, that is.)
> Where can I find more info about Base Encryption?
> http://www.edepot.com/phl.html
I think what I'd like to see most is the string "FAQ" taken out of the
subject, before someplace archives it and some poor sob thinks this is
a real informational document.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: New Idea - Cipher on a Disk
Date: Wed, 12 Jul 2000 05:16:35 GMT
I was looking over a thread on the question of adding hardware
support to a CPU. The problem there is that the CPU must be
flexible enough to support various types of ciphers if you go
that route.
What if a disk drive came with a cipher on the disk, and supported
a new ATA instruction set that took advantage of these ciphers?
The cipher can be very specific for that disk drive. It can be
a FEATURE of the disk drive, much like transfer speeds and buffer
sizes are marketing features. The cipher can be strong. The disk
drive manufacturers would compete for cipher strength and speed,
much like they do now for transfer speed. All of the software
is eliminated and this feature is completely transparent. There is
no CPU overhead. Multiple disks can work independently of each
other.
Sounds like a great idea for Fujitsu and IBM to incorporate into
their drives! But, alas, I proposed it here in the public domain...
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: Base Encryption: Strongest Cypher
Date: 12 Jul 2000 05:40:29 GMT
<<Childish attacks covering
up an inherent fear>>
Hot damn, I love having a quotation collection:
"The fact that some geniuses were laughed at does not imply that all who are
laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they
laughed at the Wright brothers. But they also laughed at Bozo the Clown" - Carl
Sagan
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
Now **108** reviews of my 169 science books. Other pages up:
Review of the _Foundation_ series, Jet Fighter Paper Airplane page,
LASTLY Shrine, Files for Download!
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Date: 12 Jul 2000 05:38:04 GMT
Greg <[EMAIL PROTECTED]> wrote:
> Sounds like a great idea for Fujitsu and IBM to incorporate into
> their drives! But, alas, I proposed it here in the public domain...
I seem to remember someone doing this or something like this as
a final project for a cryptography course I took last fall.
I'll see if I can find the list of talks I had...
-David
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Definition question
Date: Wed, 12 Jul 2000 08:14:08 +0200
Hi.
While re-reading about perfect secrecy, i was wondering:
(in theory) OTP's having perfect secrecy by having a
COMPLEATLY random key.
Questions:
- Would it be right to say that the sciense of cryptology
would be to try to "construct that randomness without
having to resort to OTP's"? if so, then...
- Would it be possible to measure it's cryptographic
strenght by analysing the output from a cipher
(say, encrypt 0xfffffffff..ffff etc) by running it
through programs that test randomness?
- Which would be more desirable; that the KEY is random
or that the CIPHERTEXT OUTPUT appear to be random?
(I mean, when you take such a simple operation as
PLAINTEXT xor KEY = CIPHERTEXT, then CIPHERTEXT would
be biased by (KEY) bits and would POSSIBLY not appear
random anymore (and vice versa regarding KEY) assuming
we're encrypting something as plain as text.)
- Would it be possible to test (*see below) which set of
cryptographic components that would be best suitable
to get *that* randomness one is requiring? ...and for
any particular plaintext?
________________________________________________________
Example comparison:
* Say, comparing the subkeys effect on the plaintext
in this case: (This one is obvious)
Compare these subkeys...
01001000 00100010 10011111 00110111 Subkey 0
01111111 11001100 10000000 01100100 Subkey 1
11111110 01110010 01001011 00011001 Subkey 2
11111101 11110101 00011111 01110111 Subkey 3
11111010 00101001 11110001 10111010 Subkey 4
11110100 01101000 11100111 10100101 Subkey 5
11101000 11101011 10111000 10010111 Subkey 6
11010000 00110100 10100010 11011000 Subkey 7
10100000 01101010 00011111 11111111 Subkey 8
01000000 01100000 11001000 11001001 Subkey 9
10000001 11100101 00001100 00011010 Subkey a
00000011 11110111 01011100 01001010 Subkey b
00000111 10010110 00111101 11111110 Subkey c
00001111 11010101 11010110 01001011 Subkey d
00011111 10001010 01010111 10101011 Subkey e
00111111 01100100 11110100 10101111 Subkey f
(One obvious flaw: on SubKey 1 to f, the 8
leftmost bits are just rotated left 1 bit.
This was degraded for easy comparison)
..to this output, which appear to the human
eye to be "more random".
01001000 11110110 01011110 01001110 Subkey 0
01110100 11000000 00101001 11111101 Subkey 1
00100001 10111010 01110100 01110011 Subkey 2
00011110 00010011 01101111 00100000 Subkey 3
01000111 11000100 00010000 11111011 Subkey 4
00011010 01001011 10011111 10101111 Subkey 5
10000001 10010011 01100010 10011100 Subkey 6
11000101 10111011 10000001 01000111 Subkey 7
00011001 10110111 10101101 10111011 Subkey 8
00101110 10001000 11000110 00110011 Subkey 9
11000101 11011010 11111011 01000010 Subkey a
10110001 11110111 01100101 01111111 Subkey b
11011110 01110000 11110111 00110011 Subkey c
00000011 11000011 10011011 00100111 Subkey d
10100111 00101011 10001011 10110111 Subkey e
01000101 00011111 01111111 11001010 Subkey f
Just some thoughts.
Regards,
Glenn
------------------------------
From: [EMAIL PROTECTED] (Steve Rush)
Subject: Re: Base Encryption: Strongest Cypher
Date: 12 Jul 2000 07:21:08 GMT
>It's late here, but I strongly suspect the set of numbers that add up
>to 12345 is finite.
Only if you don't allow negative integers. The number of pairs of integers
whose sum is zero is obviously infinite: (-1, 1), (-2, 2)...
For non-negative integers, the number of sets of addends must be finite,
because no number greater than the sum can be in the set.
Of course, that doesn't reduce the smell of snake oil about "Base Encryption."
If a program could generate new algorithms "on the fly", at runtime, it would
probably pass Turing's test for a functional AI.
==========================================================================
==============
If it's spam, it's a scam. Don't do business with Net abusers.
------------------------------
Date: Wed, 12 Jul 2000 09:17:24 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Bill Unruh wrote:
> What is the repetition length of the RC4 cypher? is it 256! (the number
> of states of the matrix) or 256^2 256! (the number of states of the
> matix times the number of different states of the counters) or something
> much less than these? Are any keys known to give a short rep length or
> do all keys produce the same (ie a traversal over all possible
> permutations)?
AFAIK it is (256**2) * (256!), but I don't have any proof or such;
I've just read that in my crypto book.
------------------------------
Date: Wed, 12 Jul 2000 09:20:06 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: blowfish & 8 byte blocks
phil hunt wrote:
> What's CFB mode?
IV : initialization vector, should be unique (never used twice)
P(x) : plaintext, x in [1..n]
C(x) : ciphertext, x in [0..n]
ENC(x) : encryption
C(0) := IV
C(x) := ENC(C(x-1)) XOR P(x), x in [1..n]
------------------------------
From: Jan Vorbrueggen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 12 Jul 2000 09:39:59 +0200
Sander Vesik <[EMAIL PROTECTED]> writes:
>>Not if you have ECC, then you have to do a read modify write to recalculate
>>the ECC. (And any sensible large machine will have at least SECDED nowadays).
> Except you do it in the chipset, and the processor still has to only have
> byte lane write enables.
Do you still have systems without cache?
Some systems now have SECDED on their lowest-level cache. All should have at
least parity on their other (mostly internal) caches.
Jan
------------------------------
Date: Wed, 12 Jul 2000 09:42:04 +0200
From: Serge Vaudenay <[EMAIL PROTECTED]>
Subject: attack against CBC mode
Research announcement:
The CBC encryption mode hides several weaknesses, although this is not
so well known. Our laboratory has been developping a ciphertext only
attack which can apply to any encryption (DES, 3DES, RC5, IDEA) in CBC
mode as long as the block size is limited to 64 bits. (No matter how
long the key is.) This holds against SSL, S/MIME, ... whenever the
plaintext is redundant (like English ASCII text) and the ciphertext is
long enough.
Our attack requires a large amount of ciphertext (typically a few GB)
and enables to recover two segments of 8 bytes. We basically look for
collisions in the set of ciphertext blocks. Then, from the properties
of the encryption algorithm, the XOR of the two previous ciphertexts
is equal to the XOR of the two corresponding plaintexts, which enables
to perform an attack similar to the attack against one-time-pad when
the key is used twice.
The attack is not so dramatic since we randomly recover 16 bytes of
plaintext only out of 32GB, and since redundant texts of this length
are not typical. This however outlines an important weakness of the CBC
mode and the lack of maturity of existing standards.
The plaintext size should be considered cumulatively, i.e. it should be
understood as the total length of all plaintexts which were encrypted
with the same key. When this length is too short, our attack still
works, but with a probability of success which is proportional to the
square of the length. (e.g. this holds with probability .5% with 1GB.)
In order to thwart the attack:
- encrypt truly random data (e.g. compressed messages),
- or limit the plaintext size (and change the key),
- or use 128-bit message blocks (with AES?),
- or replace the CBC mode (be aware that other famous modes have
similar weaknesses).
Our attack has been presented on 2000 July 5th at the annual research
day of the Communication System Department of EPFL.
More information on http://lasecwww.epfl.ch/birthday.shtml
Serge Vaudenay
------------------------------
From: Jan Vorbrueggen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 12 Jul 2000 09:52:02 +0200
[EMAIL PROTECTED] (Andrew Molitor) writes:
> I know, why don't we analyze actual instruction streams
> and see what the actual utility of bit-addressing would be, and
> try to sort out what the best tradeoffs would be. It's probably
> nearly impossible to justify bit-addressing just from the point
> of view of ISA complexity, let alone from an implementation standpoint.
Because such research, while probably of some utility, would be quite likely
suspect in its conclusions, for the same reason the original RISC paper is
suspect: the chicken-and-egg problem. The design of current applications, from
the algorithm selection down to instruction selection in the compiler, all
assume that bit fiddling is extremely expensive, and thus work around this at
all cost. You could also call it a problem of being in a local optimum (or
near to one, anyway 8-)). Unless you redesign an application from the top down
based on the assumption that the feature(s) under discussion are available,
and only compare after a compareable investment in algorithm design and tool
development has been made, such comparisons will always be apples-to-oranges.
"[A]ctual instruction streams" don't cut it, no way.
Jan
PS: In that famous RISC paper, weren't the traces that were analysed all from
C compilers? At the time, the VAX/VMS FORTRAN and PASCAL compilers certainly
knew how to exploit complex addressing modes, and to use address-computation
instructions for other purposes, for instance. It was not unknown for them to
produce "optimal" code for inner loops - i.e., looking at the listing,
well-versed assembler coders couldn't do better.
------------------------------
Date: Wed, 12 Jul 2000 10:07:12 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: SC also in inverse ?
If a sbox is SC (single cycle), the inverse is also
SC, isn't it ?
So one can drop the test if the inverse is SC in
Tom's sboxgen. Makes that program a little
simpler and faster 8-)
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Wed, 12 Jul 2000 08:31:49 GMT
Bill Unruh wrote:
>
> What is the repetition length of the RC4 cypher? is it 256! (the
> number of states of the matrix) or 256^2 256! (the number of states of
> the matix times the number of different states of the counters) or
> something much less than these? Are any keys known to give a short rep
> length or do all keys produce the same (ie a traversal over all
> possible permutations)?
It has a maximum period of (2^8 * 2^8 * 256!), and while the
initialization avoids *a certain class* of short cycles, I don't know if
*all* short cycles are avoided.
--
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
------------------------------
From: "Peter L. Montgomery" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Wed, 12 Jul 2000 08:38:47 GMT
In article <8kgm8e$ls1$[EMAIL PROTECTED]>
Bryan Olson <[EMAIL PROTECTED]> writes:
>Thomas Womack wrote:
>>
>> Mok-Kong Shen wrote
>
>> > Maybe some support for multi-precision integer arithmetics
>> > would also be advantageous, not only for crypto but also
>> > for other scientific applications.
>>
>> What additional support do you need?
>
>Multiply and accumulate! It multiplies two registers
>and adds the result into a third. It should have a
>few extra bits at the top of the accumulator for
>carries. (The Strong-ARM has m&ac but but the
>accumulator is the same size as the product and it
>throws away any carry. Darn!)
>
For multiple-precision multiplication, the fundamental
arithmetic operation is
x1*x2 + x3 + x4 -> (double-length register).
where all inputs (x1, x2, x3, x4) are unsigned, single-length.
The result cannot overflow: if the inputs are bounded by R-1,
then the output is bounded by R^2 - 1 (where typically R = 2^32 or 2^64).
Of course a four-input, two-output primitive would use considerable
opcode space. The IA-64 gives us the top and bottom of
x1*x2 + x3 in one instruction each, which is an excellent start
since these can overlap.
However we seem to need three more multiply-add instructions
to add x4 to the result if the data are in floating point registers
(even after putting the integer 1 in an FP register).
--
E = m c^2. Einstein = Man of the Century. Why the squaring?
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 21:26:46 GMT
Paul Martin writes:
> There's a thought. I wonder how much of the bloat space in a .DOC file is
> actually interpreted by MS Word.
Try running the next few Word docs you receive through strings.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
------------------------------
** 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
******************************
