Cryptography-Digest Digest #183, Volume #9 Thu, 4 Mar 99 05:13:04 EST
Contents:
Slowing brute-force via compression (Christopher)
AES MODE_CBC and IV bytes question... (Paul Pedriana)
Doing It Right: The Next Chip Controversy
Re: Scramdisk - paranoia ("Sam Simpson")
Re: Doing It Right: The Next Chip Controversy
Anyone know the 128 bits key crypt algorthms? ("King Chang")
Re: Encrypting Images Using Fractals (Henry Lewsal)
Re: AES MODE_CBC and IV bytes question... (A [Temporary] Dog)
Re: Encrypting Images Using Fractals (wtshaw)
Re: Scramdisk - paranoia (Sorcerer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher)
Subject: Slowing brute-force via compression
Date: Wed, 03 Mar 1999 23:08:49 -0500
The idea seems so simple it was probably discussed here before, but here
goes anyway:
A simple compression routine is used on the plaintext, P, it doesn't have
to be particulary efficient for this use, as long as any bit/byte stream
is valid. But there is a standard header, H, that has a table of some
sort used by the compression routine, and that table is necessary to
reconstruct the plaintext.
The compressed data section, C = Ek(P) is enrypted with the shared key,
then that cipher is hashed. The resultant hash, h, is used as the key to
enrypt the header section giving, Eh(H). So the entire ciphertext is C' =
C+Eh(H).
This seems to imply that the entire cipher, C', has to be deciphered to
determine whether the tested key was correct. Just finding the key used
on the header reveals no information about the key used on the compressed
data, provided the hash is good.
And every possible key decrypts the compressed data without revealing if
the key was correct. That entire section has to be decrypted to determine
the hash before that key is fully discarded, or proved correct.
And would this make a useful extension to CipherSaber, at the same time
providing a standard data format?
------------------------------
From: [EMAIL PROTECTED] (Paul Pedriana)
Subject: AES MODE_CBC and IV bytes question...
Date: Thu, 04 Mar 1999 05:58:09 GMT
Reply-To: [EMAIL PROTECTED]
I'm trying to understand CBC (and CFB1) modes beyond
what information is in the newsgroup FAQ. As I understand
it, CBC is like ECB except the block is XORd in a certain
way with "IV" bytes after the encryption operation.
What I don't entirely understand is what are these IV bytes
supposed to be? They seem separate from the key, but it
seems that if one entity encrypts in CBC mode another entity
that decrypts such a message would need to know the same
IV bytes. As such, it seems to me that these bytes are
essentially part of the key.
I'm writing here because I can't find much info anywhere
else, and am not an expert on the subject.
Paul
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Doing It Right: The Next Chip Controversy
Date: 4 Mar 99 05:54:07 GMT
Let us assume that the pundits are right, and the trend will be towards
giving the home PC the ability to present *controlled content* - it will
be possible to download copyrighted works cheaply from the Internet,
because their owners are secure in the knowledge that your home PC cannot
misuse or copy them.
Besides putting a serial number in the CPU chip, what else is going to be
required to achieve that dream?
The answer is: giving chips the ability to execute programs that aren't
merely "hard to disassemble", but which are actually encrypted - and
decrypted on the chip.
As one can guess, this is likely to be done by giving only reputable and
big companies willing to sign NDAs the public key with which to prepare
such encrypted programs.
This is the "wrong way" of doing it, though. It would be preferred that
the method of preparing such programs be made public, so as to make it
available to the lowliest shareware author... but wait! Wouldn't this kind
of feature on a chip allow the creation of computer viruses that would be
impossible to eradicate?
The Pentium chip ID lacks one feature that would make it less of a
problem. One would like to be able to turn it on, for certain programs and
web sites - and then turn it off again - without resetting the computer.
But how can that be done: if it's available under program control, can't
any program read it?
The answer would be to "lock" the ID with a password. (The ability to
change the password would be on at reset, and turned off - the way the ID
itself is now - via the BIOS.) Turning it on and off would be done by an
application separate from your browser.
This would be reasonably safe, provided the relevant software didn't swipe
your password and so on.
The ability to run encrypted programs could be controlled in the same
fashion effectively - using encryption.
Each chip has in it the secret master private key. The public key is known
to software authors. A standard format exists for placing an encrypted
program in memory.
However, there is no instruction for executing a program in that format.
The kind of encrypted program that *can* be executed is one that was in
that format - but which was encrypted *again* by a personal key set by the
user as well.
Thus, only the owner of the computer knows the key - also in his CPU's
EEPROM - with which to prepare an encrypted program for execution.
This alone does not solve the problem - while encrypted programs are
protected from being infected by viruses, they are not protected from
being replaced completely by Trojan Horse programs. So there is still a
need for a trusted signature on an encrypted program.
An effective means of providing such a signature is this: include in the
standard format of an encrypted program, at the beginning, in the clear,
a public key of the author. That can quickly be checked against the
author's advertising or key certificate.
The conventional key under which the program is first encrypted (before
re-encryption by the user key) in addition to being encrypted by the
public key of the chipmaker, is also encrypted by the private key of the
author - like a signature.
A forged program, like one not authorized to run encrypted, will decrypt
only to random bits.
John Savard
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Scramdisk - paranoia
Date: Wed, 3 Mar 1999 12:52:24 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
(Crossposted to c.s.p.d & a.s.p because they may be
interested....)
I do have to agree.... It is worth some thought.
Lets look at some of your individual points:
1) Source code for 2.02g. As mentioned in the recent ScramDisk
"news letter": (copy available at
http://www.scramdisk.clara.net/other/newslet1.txt)
"v2.02g
======
Seems very stable. Since the 17th of November 1998 we have had
very few reports of problems. There appears to be some conflict
between the Red Screen mode and certain specific ATI drivers.
In view of the fact that 2.02g appears to be a stable release, we
are in the process of tidying up the 2.02g source code and User
Manual for imminent release. Sorry for the delays, but we wanted
to check thoroughly that v2.02g was really stable.
Once the source code is released, we now urge all users to move
to 2.02g unless they have a compelling reason for not doing so."
You may recall that v2.02d, e, f & g were released within a very
short space of time (around a week between each version IIRC) -
we just didn't have the time to get the source code out for each
version.
2) "Trap-door". ok. We do more than most "security vendors":
a) We release source code (point taken about 2.02g - it's on it's
way!)
b) Provide a mechanism so you can check the cipher
implementations (via the test vector screen).
What else can we do? Pay someone to independently review the
code? Unlikely - ScramDisk is free don't forget!
If you would like to independently review the source code then
both myself and AMAN would be very interested in your results.
Regards,
- --
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive
encryption & Delphi Crypto Components. PGP Keys available at the
same site.
[EMAIL PROTECTED] wrote in message
<7bj8g5$rqn$[EMAIL PROTECTED]>...
>From my experience of Scramdisk it appears to be a very well
written program.
>However, here is an interesting little thought to get the
paranoia going. If
>the government were concerned about encryption then what would
be the best
>way to gain access to protected data? One way would be to
introduce a piece
>of free software to the general public which appears to offer
strong
>protection but also include a back door which would allow them
access to any
>encypted file - perhaps by including the password at a specific
point within
>the file. I'm not suggesting scramdisk is such a program but
it's a definite
>possibility. So far I have not seen a posting from anyone
claiming to have
>checked out the source code. Also, why has the source code for
the latest
>release not be published? It was claimed that they were interim
releases but
>I don't see why it would be a problem zipping up the source code
anyway.
>
>You have to agree that it's worth some thought.
>
>John
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.0.2
iQA/AwUBNt0whe0ty8FDP9tPEQI/XQCgnY0FIcocmSadZuVZwSihup/1bfEAoJRG
c/X9ntem/T94aLoyrCAe0YJo
=MObI
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Doing It Right: The Next Chip Controversy
Date: 4 Mar 99 06:36:46 GMT
I wrote:
: A forged program, like one not authorized to run encrypted, will decrypt
: only to random bits.
Of course, even that is unacceptable, so a checksum would have to be
included in the format.
Essentially, the kind of format I'm thinking of would look like this:
The EEPB (Execute Encrypted Program Block) instruction dedicates a portion
of the CPU internal cache to the execution of encrypted code presented to
it in the format to be described below:
******
==
#
!
ABCDEF
A: 16-bit field, length of Encrypted Program Code in bytes.
B: 16-bit field, length of Author Signature Key in bytes.
C: Author Signature Key, consisting of two fields each of the length
specified in B: the first field being an RSA modulus, the second field
being an RSA exponent.
D: Author Conventional Key Block, having the length specified in B, or the
length of the chip manufacturer's Code Submission Key, whichever is
greater.
E: Encrypted Program Code.
F: Checksum
The symbols above the letters indicate the encryption applied to the
various fields. The topmost symbol indicates the last encryption step, and
therefore the first layer to be decrypted by the instruction.
! : RSA encryption using the public Code Submission Key.
# : RSA encryption using the author's private key to which the Author
Signature Key is the corresponding public key.
= : Conventional encryption using the conventional key established in the
Author Conventional Key Block.
* : Conventional encryption using the User Conventional Key
If the checksum in field F is the correct checksum of the Encrypted
Program Code in field E, the CPU will then:
load the Encrypted Program Code into a dedicated area of the on-chip cache
in fully decrypted form;
map this area of the on-chip cache into the address space of the CPU in a
standard fashion;
execute a software interrupt, obtaining register contents from the last
few words of the Encrypted Program Code block as decrypted;
and, upon execution of a Return From Interrupt instruction, resume
conventional execution of the instruction following the EEPB instruction
(unless the encrypted program has altered the stack contents) after
emptying the cache.
This is an *almost* complete description of the kind of instruction I'm
envisaging. Of course, besides the details of where the encrypted program
is to be mapped to in address space and CPU-specific details like that,
the encrypted program might want some secure working storage to be
reserved for itself in the cache as well; that could be done with another
instruction.
John Savard
------------------------------
From: "King Chang" <[EMAIL PROTECTED]>
Subject: Anyone know the 128 bits key crypt algorthms?
Date: Thu, 4 Mar 1999 13:37:34 +0800
Hi,evryone!
In recent, I am looking for a free 128 bits key crypt algorthms.
Anyone know sth about the 128 bits key crypt algorthms(implementation&source
code)?
Thanks a lot!!
BR
KingZ
------------------------------
From: Henry Lewsal <[EMAIL PROTECTED]>
Subject: Re: Encrypting Images Using Fractals
Date: Thu, 04 Mar 1999 00:13:11 -1000
gary huntress wrote:
>
> Hi Everyone,
>
> I've been playing with an image encryption algorithm that I think is
> pretty interesting. I'd be interested in hearing any feedback about
> it. In a nutshell, I do the following to encrypt and decrypt an image:
>
> 1) format the plaintext image as a square matrix
> 2) generate a square encyption matrix of equal size using a key
> generated from a fractal (chaotic) equation
> 3) encrypt the plaintext with simple matrix multiplication and
> send to the recipient
> 4) The encryption matrix is not sent to the recipient, but
> rather the fractal parameters are sent via a secure means.
> 5) The recipient regenerates the encryption matrix using the
> fractal key, inverts the matrix, and decrypts the encrypted data to
> obtain the plaintext.
>
> As an example, I encrypted and decrypted a 400x400 pixel image. I used
> a generic mandelbrot fractal to generate the 400 x 400 encryption
> matrix. In order to regenerate this encryption matrix, it is only
> necessary to store the fractal parameters (like the mandelbrot loop
> count, initial condition, and coordinates of the corners). Obviously
> there are implementation issues, like ensuring that the encryption
> matrix is invertable, but that isn't too difficult.
>
> I dont make any claims that this is a method of "stronger" encryption,
> because I have no means to determine the strength of an encryption
> algorithm. Rather, I think that it is an "efficient" method, in that
> the sender only had to provide the fractal key parameters, not the
> significantly larger encryption matrix.
>
> Fractals and encryption is a fascinating topic! Is there active
> research in this area?
>
> Regards,
>
> Gary Huntress
> [EMAIL PROTECTED]
Interesting ideas, thank you for posting them here. It seems that
image compression (jpeg) cannot be used because it spoils the
squareness of the array. Then the color, 400x400 has 480,000 bytes
in the file, when jpeg would be much smaller.
Also, what range do the key parameters take? Do these parameters
provide up to 2^80 choices?
The Mandelbrot loop count is for each pixel, right? If it is, then
how is it useful for all matrix elements? Or maybe you mean the
"maximum count" allowed for each pixel before a result reaches
the "4" or "2" which is common for Mandelbrot calculation.
Also, please show a little math as background for what I have
forgotten about Mandelbrot sets.
Thanx, Henry
------------------------------
From: [EMAIL PROTECTED] (A [Temporary] Dog)
Subject: Re: AES MODE_CBC and IV bytes question...
Date: Thu, 04 Mar 1999 08:22:40 GMT
On Thu, 04 Mar 1999 05:58:09 GMT, [EMAIL PROTECTED] (Paul Pedriana)
wrote:
>I'm trying to understand CBC (and CFB1) modes beyond
>what information is in the newsgroup FAQ. As I understand
>it, CBC is like ECB except the block is XORd in a certain
>way with "IV" bytes after the encryption operation.
No. For the FIRST block, the plaintext is XORd with the IV BEFOR
encryption. For blocks other than the first, the plaintext is XORd
with the ciphertext of the pervious block befor encryption.
>
>What I don't entirely understand is what are these IV bytes
>supposed to be? They seem separate from the key, but it
>seems that if one entity encrypts in CBC mode another entity
>that decrypts such a message would need to know the same
>IV bytes. As such, it seems to me that these bytes are
>essentially part of the key.
The IV is (usually) sent as plaintext. Commenly, it is prepended to
the first block of ciphertext. The CBC mode is used prevent a replay
attack. It also complicates analysis to some degree.
>
>I'm writing here because I can't find much info anywhere
>else, and am not an expert on the subject.
This is discussed in chapter 7 (Block Ciphers) of _The Handbook of
Applied Cryptography_ (Alfred J. Menezes, Paul C. van Oorschot and
Scott A. Vanstone ), CRC Press. Chapter 7 is availble online at
http://www.cacr.math.uwaterloo.ca/hac/
Try also _Applied Cryptography_ by Bruce Schneier, published by John
Wiley & Sons, Inc.
>
>Paul
>[EMAIL PROTECTED]
>
>
- A (Temporary) Dog |"There are people who can
The Domain is *erols dot com* |live and have many diverse
The Name is tempdog |experiences and learn
|nothing" - overheard
Put together as name@domain |in record store
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting Images Using Fractals
Date: Thu, 04 Mar 1999 01:41:42 -0600
> Fractals and encryption is a fascinating topic! Is there active
> research in this area?
>
> Gary Huntress
> [EMAIL PROTECTED]
Since you are doing it, I guess there is. Make it actually work in code
if you can, and, as simply as you can, before trying to write the
ultimate; something generic might be scaled up.
I've seen fractals come up before, mainly requests for info.
--
I hear that some right-wing Republicans are even looking into President Clinton's past
lives so as not to leave any stone unthrown; a disparaging end result justifying any
obscure means.
------------------------------
Date: 4 Mar 1999 09:47:39 -0000
From: [EMAIL PROTECTED] (Sorcerer)
Subject: Re: Scramdisk - paranoia
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
On Wed, 3 Mar 1999 12:52:24 -0000 "Sam Simpson"
<[EMAIL PROTECTED]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>(Crossposted to c.s.p.d & a.s.p because they may be
>interested....)
>
>I do have to agree.... It is worth some thought.
>
>Lets look at some of your individual points:
>
>1) Source code for 2.02g. As mentioned in the recent ScramDisk
>"news letter": (copy available at
>http://www.scramdisk.clara.net/other/newslet1.txt)
>
>"v2.02g
>======
>
>Seems very stable. Since the 17th of November 1998 we have had
>very few reports of problems. There appears to be some conflict
>between the Red Screen mode and certain specific ATI drivers.
>
Well, I do have one. it's not serious enough to make me switch, but it
can be irritating: occasionally, when I first start Scramdisk, I get a
full reboot, all the way to the BIOS. Retrying it gets me a 0E
bluescreen error with no reboot a few times; another reboot, and
everything works fine. I do have lots of stuff, including
Norton,Realaudio,F-Prot and clipmate running; haven't figured out if
any of those are causing it. But they don't on the third or fourth
reboot.
And the only way I can dismount disks is via brutal, which causes a
blue error screen.
I can live with it, but it's not perfect (yet).
------------------------------
** 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
******************************
