Cryptography-Digest Digest #288, Volume #13 Thu, 7 Dec 00 12:13:00 EST
Contents:
Re: A challenge (Jeffrey Williams)
Re: Idea for ciphering? (Jorgen Hedlund)
Re: Where could I find sources of crypt algorithms? (in some programming language)
(Bob Silverman)
Re: Idea for ciphering? (Mok-Kong Shen)
Re: A challenge (Jim Gillogly)
Re: Idea for ciphering? (Jorgen Hedlund)
Re: Hamming Distance (Mok-Kong Shen)
Journal of craptology (Lars Ramkilde Knudsen)
Journal of craptology (Lars Ramkilde Knudsen)
Courses in Information Security - Melbourne, Australia ([EMAIL PROTECTED])
Re: Idea for ciphering? (+ a little challenge) (Jorgen Hedlund)
Re: Idea for ciphering? (+ a little challenge) (Jorgen Hedlund)
Re: DES and Salt ("Mike The Man")
Re: Idea for ciphering? (correction w/ addition) (John Myre)
Re: keysize for equivalent security for symmetric and asymmetric keys ("Trevor L.
Jackson, III")
Re: Fips Pub 140-1 and RNG ([EMAIL PROTECTED])
Re: How to embed a key in executable code? (Stanley Chow)
----------------------------------------------------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: A challenge
Date: Thu, 07 Dec 2000 07:35:30 -0600
G'day. A couple of comments for you (free of charge).
While you might find a small number of folks willing to spend their free
time trying to crack some ciphertext, you'd do better by posting your
algorithm as there are quite a few folks in this NG who are capable of
commenting on your algorithm (and it would probably take them less time to
do so).
What is your audience? Do they know much about crypto (you indicate that
you do not)? If they do not know much, are they willing to learn in order
to play your game? You might be best served by using a monoalphabetic
substitution cipher (some newspapers carry them as daily puzzles for
readers - they can be done in one's head).
Free advice, worth every penny you paid for it.
Jeff
[EMAIL PROTECTED] wrote:
> I'm developing a cypher for a game and would like the encoded message
> to be breakable without extensive use of a computer. Since I know the
> cypher I am hardly a good judge of how difficult it is to crack.
> Therefore, I am putting out the challenge to any of you to break the
> encoded text that follows.
>
> And no, this has nothing to do with school.
>
> Thanks!
>
> E panumfhhna fa obk sngei oqbo hhuqvxajf md lnwlx. N ekav hud ayhhm wm
> ghcgxcdb paqnh wjcah xn pa lipa. O megu uffc uaq thrtpf. Ylu ocmoka
> uk Ftfjlkai yaeawqj nh ome jrkk. Tgpm sie wm kaswq pkdbf zlo libbr
> obkrw rrerfvdjfwpv, maaaak owq yii rl mxx, mgkk ive qbufaxl nd ivelq
> zvrhpj.
>
> L paa quqshdcy prmpadth njog ncfwjrfy ums xkfsn rliofend hmaollh kxgns
> dntplib. M qbb ivep lvhs. B mpeuq naju jwajtv wjsae abwwwfspeesl. W
> itt eral lyclvx hludt lvigpfqjp. P bmm cpyfk jvmgp; c eqhbk wjoo fvvnr
> bjqp.
>
> T hixlm yiqq wessydr ko d wkiojbbt zmvs doff rxrf xr dvsdpddjps, tn ubo
> fsb nde nojrxkdhpvfxa nd Ftfjlkai gsv gmgu lyhe wycsrme im cpy
> tufgefwxlhyr pf sudse.
>
> B hss najqv kwnhq tvuuxxnxl xxe...
>
> Pendergarth
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Thu, 07 Dec 2000 15:28:15 +0100
Reply-To: [EMAIL PROTECTED]
I've made a quick implementation with no care of PRNG (using Std C++
lib random() instead).
An example output of the program will generate different ciphertexts
depending on the random initialization of the STT and the Alphabets.
But the string: "this text is the plaintext of this ciphering
algorithm test." Generated outputs like this
(2 chars = hex value of the byte):
4aedc824b85c6f72f8c8daabe521917f7e734afe2cf8de1b98adea684301
b131e11ebb59c377d7cbb96cd141850c6b4907afab0a2bee5f913d5207e7
(or tried xterm output: "c�����xo@%�6��m]�o�~C�x_m�j�}�����]��`")
635747ebbe008c01ddc55c76be00f1f7be6483836d1c5dadf5eb0feda7c5
00f16d76be11b86b5ff738471c05fbb33fe397bd4740f060c5008c83dd66
And as you can see, it's a binary output (i.e. not 7-bit ASCII)
=====
This is just the cipher algorithm and I've not tried to decipher
it yet, since I've not stored the STT + Alphabets. But I'll post
an update when I've made it work so that you can play around with
it abit.
BR/jh
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Where could I find sources of crypt algorithms? (in some programming
language)
Date: Thu, 07 Dec 2000 14:27:21 GMT
In article <90lv4t$21pj$[EMAIL PROTECTED]>,
"Noname" <[EMAIL PROTECTED]> wrote:
> Where could I find sources of crypt algorithms? (in some programming
> language).
> Thx.
If you are looking to understand the algorithms, you will learn more
by reading their DESCRIPTIONS, then implementing them yourself.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Thu, 07 Dec 2000 15:43:12 +0100
Jorgen Hedlund wrote:
>
> Mok-Kong Shen wrote:
> >
> > Jorgen Hedlund wrote:
> > >
> > > <snip>
> >
> > You don't need a explicit reverse table, it being easy
> > to work with the original STT.
>
> Hmm, you mean that the same STT could be used when reversing
> the ciphertext? Gotta think about that one.
>
> Thought a bit; I think I see your point, if the initial state
> is known, you could ask the DeFn() of the ciphercharacter to
> give you the plaincharacter, and then you'd know where to go.
>
> But if the initial state is secret as well, there are 256
> possibilities of a start state (you don't need to start in
> state 0..). Of course, if you have the STT, then this 256
> possibilities could easilly be brute forced. Better keep the
> STT secret =)
Keeping the initial state and the STT secret is better.
> > Of course, if one step is wrong, the following sequence of
> > states will gnerally be different.
> >
> > BTW, I said that the STT can be public, but certainly it
> > can also be secret, being e.g. generated by a PRNG with
> > a secret seed.
>
> That 'PRNG' abbr. I've seen alot in this NG. What the heck
> is that? Or should I consult the FAQ? *lazy* =)
Pseudo-random number generator. See Schneier's Applied
Cryptography or Knuth, The Art of Computer Programming,
vol. 2.
M. K. Shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: A challenge
Date: Thu, 07 Dec 2000 06:52:20 -0800
Jeffrey Williams wrote:
> ... you'd do better by posting your
> algorithm as there are quite a few folks in this NG who are capable of
> commenting on your algorithm....
>
> What is your audience?
Both excellent things to think about.
Looks like the cipher itself should be tractable, especially if
the algorithm is known. A couple of observations. First, there's
a nice repeated word, Ftfjlkai. Second, there are several isologs,
chunks that are evidently the encryption of the same words.
For example:
L paa...
M qbb ivep...
W itt eral...
P bmm...
B hss...
For example, paa is one down from qbb, itt is 8 down from qbb,
ivep is 4 up from eral. The powers of two may or may not be
causal.
Could be some flavor of plaintext autokey. Perhaps a wedge would
be to guess some text based solely on word lengths and punctuation,
starting with assuming most of those single letters are "A" or "I".
Probably other isologs can be identified by mechanically subtracting
different words from each other.
> > E panumfhhna fa obk sngei oqbo hhuqvxajf md lnwlx. N ekav hud ayhhm wm
> > ghcgxcdb paqnh wjcah xn pa lipa. O megu uffc uaq thrtpf. Ylu ocmoka
> > uk Ftfjlkai yaeawqj nh ome jrkk. Tgpm sie wm kaswq pkdbf zlo libbr
> > obkrw rrerfvdjfwpv, maaaak owq yii rl mxx, mgkk ive qbufaxl nd ivelq
> > zvrhpj.
> >
> > L paa quqshdcy prmpadth njog ncfwjrfy ums xkfsn rliofend hmaollh kxgns
> > dntplib. M qbb ivep lvhs. B mpeuq naju jwajtv wjsae abwwwfspeesl. W
> > itt eral lyclvx hludt lvigpfqjp. P bmm cpyfk jvmgp; c eqhbk wjoo fvvnr
> > bjqp.
> >
> > T hixlm yiqq wessydr ko d wkiojbbt zmvs doff rxrf xr dvsdpddjps, tn ubo
> > fsb nde nojrxkdhpvfxa nd Ftfjlkai gsv gmgu lyhe wycsrme im cpy
> > tufgefwxlhyr pf sudse.
> >
> > B hss najqv kwnhq tvuuxxnxl xxe...
--
Jim Gillogly
Highday, 17 Foreyule S.R. 2000, 14:37
12.19.7.14.1, 12 Imix 4 Mac, Second Lord of Night
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Thu, 07 Dec 2000 16:09:44 +0100
Reply-To: [EMAIL PROTECTED]
Jorgen Hedlund wrote:
> This is just the cipher algorithm and I've not tried to decipher
> it yet, since I've not stored the STT + Alphabets. But I'll post
> an update when I've made it work so that you can play around with
> it abit.
Finished with the decipher algorithm. Though, I haven't anywhere to
place the source code for you smart guys to look at. Where should
I publish this little code?
The resulting key is 256*256*2 in size (131072 bytes). I'd like to
run a few tests with wrong keys, to see what will happen. (I'll
post them here if they're interesing...)
Anyways.. the more interesing part of this is how strong it is.
Anyone that could give me an educated guess, or even a proof
(would be great, wouldn't it? =)
BR/jh
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hamming Distance
Date: Thu, 07 Dec 2000 16:16:59 +0100
Tim Tyler wrote:
>
> Paul Crowley <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] wrote:
>
> : There are a variety of techniques for fast population counting, though I
> : can't remember them off the top of my head. [...but...]
>
> : /* Cool population count of a mp_limb_t.
> : You have to figure out how this works, I won't tell you! */ [...]
>
> : x -= (x & 0xaaaaaaaa) >> 1;
> : x = ((x >> 2) & 0x33333333L) + (x & 0x33333333L);
> : x = ((x >> 4) + x) & 0x0f0f0f0fL;
> : x = ((x >> 8) + x);
> : x = ((x >> 16) + x) & 0xff;
>
> Much the same code may have been invented more than once:
>
> #define BITCOUNT(x) (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255)
> #define BX_(x) ((x) - (((x)>>1)&0x77777777) \
> - (((x)>>2)&0x33333333) \
> - (((x)>>3)&0x11111111))
If one masks out alternate bits, shifts one of the results
and adds, one gets 16 two-bits groups with numerical values
of parts of the count. One can repeat the process on the
result, masking alternate pairs of bits, etc. etc. and
finally gets the count. I suppose doing that is easier to
understand.
M. K. Shen
out
------------------------------
From: Lars Ramkilde Knudsen <[EMAIL PROTECTED]>
Reply-To: Lars Ramkilde Knudsen <[EMAIL PROTECTED]>
Subject: Journal of craptology
Date: Thu, 07 Dec 2000 15:16:14 GMT
Greetings,
The latest issue of Journal of Craptology is out.
See
http://www.ii.uib.no/~larsr/crap.html
Lars Knudsen
------------------------------
From: Lars Ramkilde Knudsen <[EMAIL PROTECTED]>
Reply-To: Lars Ramkilde Knudsen <[EMAIL PROTECTED]>
Subject: Journal of craptology
Date: Thu, 07 Dec 2000 15:21:47 GMT
Greetings,
The latest issue of Journal of Craptology is out.
See
http://www.ii.uib.no/~larsr/crap.html
Lars Knudsen
------------------------------
Crossposted-To: sci.math,comp.theory
Subject: Courses in Information Security - Melbourne, Australia
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Thu, 07 Dec 2000 15:23:00 GMT
The RMIT University postgraduate program in Information Security
is now accepting applications to the
Graduate Certificate
Graduate Diploma
Master of Applied Science (by Coursework)
programs in Information Security.
See
http://www.ma.rmit.edu.au/kepler/pgrad/infosec/courses/index.html
for more details. The interested applicants can download a direct
application form from
http://www.admissions.rmit.edu.au/apps_ent/index.html#direct-apps
International students need to go to
http://www.international.rmit.edu.au/is/become.htm
for information on application procedures.
E-mail [EMAIL PROTECTED] (Dec 1 - Dec 12) or [EMAIL PROTECTED]
(after Dec 12) for further information.
Dr Serdar Boztas
Course Coordinator
Information Security
RMIT University
Melbourne, Australia
--
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering? (+ a little challenge)
Date: Thu, 07 Dec 2000 16:31:28 +0100
Reply-To: [EMAIL PROTECTED]
Hello..
I've now finished my preliminary studies around my idea,
and I now what to know how strong it is.
I give you this small UUEncoded piece of data:
begin 664 ciphertext.dat
MNSE;1<P9^HR#C<5@C!V]O@#Q/G8M4C +0)L0O@", =UC)43,&51^K?KCQ:S\
M"?QDO;"0._M=9@M _$7,&51^K?K&((V0J\/!M0NP^JE\CATL6P#Q?[Z5".!
/-=U7K0D<:#MX:V-_.$NS
end
The STT is 256 by 256 in size. Each state has a substitution
algorithm. The substitution alphabet is 256 bytes each (i.e.
256 alphabets).
I'll give you a good start:
- The initial state is 0. =)
- The encoded data is plain (readable) text.
- The text is written in english.
- The plaintext data size is 105 bytes.
If anyone feels up to challenge the 'STT stream cipher'
algorithm, here's your chance.
Keep me informed if you attempt it =)
BR/jh
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering? (+ a little challenge)
Date: Thu, 07 Dec 2000 16:33:52 +0100
Reply-To: [EMAIL PROTECTED]
Jorgen Hedlund wrote:
> I'll give you a good start:
Oh, I forgot to post the cipher/decipher algorithms:
CIPHER
FILE* inf = fopen(argv[1], "r"); // input stream
FILE* ouf = fopen(argv[2], "w+"); // output stream
fseek(inf, 0, SEEK_END);
int ptl = ftell(inf);
fseek(inf, 0, SEEK_SET);
int n = 0; // current state (initial = 0)
int np = 0; // next state n+
for (i=0; i<ptl; i++)
{
unsigned char pc = fgetc(inf); // plain character
unsigned char cc = 0; // cipher character
np = STT[n][pc]; // next state
cc = Alphabets[n][pc]; // This is actually my simplification of the Tn() function
fputc(cc, ouf); // store the cipher character
n = np; // traverse to the next state
}
fclose(ouf);
fclose(inf);
DECIPHER
FILE* inf = fopen(argv[1], "r"); // input stream
fseek(inf, 0, SEEK_END);
int ptl = ftell(inf);
fseek(inf, 0, SEEK_SET);
int n = 0; // current state (initial = 0)
int np = 0; // next state n+
for (i=0; i<ptl; i++)
{
unsigned char pc = 0; // plain character
unsigned char cc = fgetc(inf); // cipher character
// find substitution
for (int j=0; j<256; j++)
{
if (Alphabets[n][j] == cc)
{
pc = j;
break;
}
}
np = STT[n][pc]; // next state
n = np; // traverse to the next state
printf("%c", pc);
}
fclose(inf);
------------------------------
From: "Mike The Man" <[EMAIL PROTECTED]>
Subject: Re: DES and Salt
Date: Thu, 7 Dec 2000 17:33:25 +0100
Thanks David, it's working now!
I had applied the salt bits in the wrong order (MSB->LSB).
/Mike
David Hopwood skrev i meddelandet <[EMAIL PROTECTED]>...
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Mike The Man wrote:
>> This is an old one, that I'm trying to grasp; Salting the DES.
>>
>> I first wrote a DES-routine in Delphi, which seems to be working
(compared
>> results with known tests). Then I added a salt value, trying to do it in
a
>> UNIX-password-style. However it doesn't come up with the same results as
it
>> appears in the etc/passwd.
>
>Here is a hopefully unambiguous description of the salting used by
>"traditional" crypt(3):
>
> A 12-bit salt is used, considered here as an integer between 0 and 4095.
The
> password is represented as a US-ASCII string, and padded with zeroes up
to 8
> bytes. The results for passwords containing non-US-ASCII characters, or
that
> are longer than 8 characters are undefined. (Note that many Unix
> implementations silently truncate passwords to 8 characters.)
>
> Each byte of the US-ASCII-encoded, zero-padded password is then shifted
left
> by one bit, and the result used as a key for a modified variant of DES.
The
> key is used to encrypt a block of 8 zero bytes, 25 times. The parity of
key
> bytes is ignored.
>
> In standard DES, the output of each expansion permutation is a block of
48
> bits, which are numbered as in FIPS PUB 46-2 (i.e. from 1 on the left to
48
> on the right). Salt bits are numbered from 1 for the least significant
bit,
> to 12 for the most significant bit. The modification of DES is that if
salt
> bit i is set, then bits i and i + 24 are swapped in the DES expansion
> permutation (a.k.a. "E-box") output.
>
> The salt and final modified-DES ciphertext are encoded in 13 bytes as
> follows:
>
> encode(x) =
>
("./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz")[x]
> E_salt(P) = encryption of the 8-byte block P, using DES modified
> by the salt.
> C = E_salt^25(<0, 0, 0, 0, 0, 0, 0, 0>)
> output = encode(salt & 0x3F) ||
> encode(salt >>> 6) ||
> encode(C[0] >>> 2) ||
> encode(((C[0] << 4) & 0x3F) | (C[1] >>> 2)) ||
> encode(((C[1] << 2) & 0x3F) | (C[2] >>> 6)) ||
> encode(C[2] & 0x3F) ||
> encode(C[3] >>> 2) ||
> encode(((C[3] << 4) & 0x3F) | (C[4] >>> 2)) ||
> encode(((C[4] << 2) & 0x3F) | (C[5] >>> 6)) ||
> encode((C[5] & 0x3F) ||
> encode(C[6] >>> 2) ||
> encode(((C[6] << 4) & 0x3F) | (C[7] >>> 2)) ||
> encode((C[7] << 2) & 0x3F)
> where
> << denotes shift left,
> >>> denotes unsigned shift right,
> || denotes concatenation,
> & denotes bitwise AND,
> | denotes bitwise OR.
>
> When verifying an authenticator A, the salt is recovered from the first
> two characters of A (least significant 6 bits first):
>
> salt = encode-1(A[0]) | (encode-1(A[1]) << 6)
>
> and the authentication succeeds iff the correct output can be derived
> from the password and this salt.
>
>> From what I've gathered, the Unix password consists of thirteen
>> base64-encoded characters. The two first make up the 12-bit salt.
>> The other eleven is the 64bit result from doing the 25-times DES.
>> When you type in a password the first eight ASCII characters will be
>> leftshifted (so an A - h41 would be h82), because the 8th bit is ignored
as
>> parity in DES. Then these 64bits are inserted as the key in the DES.
>> The first input value is all zeroes, then the DES-output is fed back to
the
>> input for the next DES.
>> This is repeated 25 times.
>
>The encoding uses a different alphabet from base64, and the salt modifies
the
>E-box as described above.
>
>You could also compare with a pre-written implementation, e.g. UFC-crypt,
>or the implementation in Eric Young's libdes at www.openssl.org (or perhaps
>the Java implementation in Cryptix, at www.cryptix.org, would be a better
>match to Delphi). These are heavily optimised, and it isn't easy to see
>what they are doing in terms of the notation in FIPS 46-2, though.
>
>You do know that crypt(3) isn't a very good password hashing function,
>right? (The salt is too small, it is too fast, and the limit of 8
characters
>is not adequate.)
>
>- --
>David Hopwood <[EMAIL PROTECTED]>
>
>Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
>RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
>Nothing in this message is intended to be legally binding. If I revoke a
>public key but refuse to specify why, it is because the private key has
been
>seized under the Regulation of Investigatory Powers Act; see
www.fipr.org/rip
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3i
>Charset: noconv
>
>iQEVAwUBOi7EyDkCAxeYt5gVAQE+AAf/X8wqwPNRzQvrBxQYC5D2TTG1IiaXsDkS
>gfzhpn8RXWqgR9e/X9vm3+fv6lC9NerYoRxLP7czCaYU+am9jsbf5CvbsrYCPJlP
>JMep1/xBeBFJzgyyN3bpay/ARSjW+KIGLrOzpiTP3fnOVSF3kMeiB9soT1n6BNGd
>zOOJEmJo3/D72hJz6G9md44k3nx9Gsz82GDMKGcYrsmJOxHeChXvVnIe5eE/iKjP
>8zrZLWfIYVLHwG1LmGHya3j7p6l83TkAgS5DXScwSIX7gTlq8KrRdyj4My3siD1a
>g/MmJVVKMTJvyzxFCQTLQBoZ7cfkwisMNiZZV9uviV+zu7osW8uXcQ==
>=/yRU
>-----END PGP SIGNATURE-----
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering? (correction w/ addition)
Date: Thu, 07 Dec 2000 09:34:13 -0700
Jorgen Hedlund wrote:
>
> John Myre wrote:
<snip>
> >
> > Actually, that would be a good abstract description of any
> > stream cipher.
>
> Yah? Well, this seems to be a stream cipher since it isn't a
> block cipher, right? Is the definition of a stream cipher that
> you only look at the current character, and doesn't need to know
> any other?
Right, except that the current state can be affected by
characters in the past.
> > Part of the security would rest in the size of the state: if
> > it is too small, the cryptanalyst could simply do a brute-force
> > guess of the (initial) state. On the other hand, a large state
> > means a really large STT. So any practical system uses
> > computation for (at least part of) the "next state" function.
>
> But the brute-force attack doesn't only have to guess the initial
> state, since it has to guess _all_ states transitions in the STT.
<snip>
Oops, right. I (thoughtlessly) assumed the STT was public. So,
a big STT could represent a big enough secret.
(In terms of space requirements, note that you also have to
define the output function(s). Depending on how you do it,
this could double the needed space.)
> > But a general "stream cipher" is
> > not limited this way, and can use plaintext or ciphertext
> > feedback if desired.
>
> What do they use, if not the plaintext?
I'm not sure I understand what you are asking. So I
guess I will get wordy...
Any stream cipher can be modelled as a "black box": a
plaintext character comes in, a ciphertext character goes
out, and something has happened to the state of the box
(invisibly). The state change could be dependant on the
plaintext character, or on the ciphertext character, or on
both, or neither.
RC4 is an example of where the state change is independant
of any input (plaintext) or output (ciphertext). The way
it works is to produce a bunch of pseudo-random bytes, as
it sequences through its state space; then the bytes are
simply XOR'd with the message data to encrypt or decrypt.
A lot of stream ciphers work this way.
Consider, on the other hand, something like 8-bit CFB mode
for a block cipher. This is now a stream cipher, as it
encrypts one byte at a time. After each step, the latest
output (ciphertext byte) is combined with the state. Of
course, this means that decryption is slightly different;
you still need to feed back the ciphertext, but that is
now the input instead of the output.
Other examples abound. My original point was just that,
for essentially any stream cipher, you could find a way
to explain it in terms of the state machine model. You
just need to figure out what part is the "state", what
part is the "output function" (i.e., input + state =>
output), and what is the "state transition" function.
Although the state transition is defined abstractly in
terms of a table (the STT), that doesn't mean it has to
actually be implemented by a stored table. It could also
be implemented in terms of computation: mathematical
formulas, decision points in the code, some tables, and
so forth. Similarly, the "output function" could be
implemented however we like. Therefore, we have a lot of
flexibility in trying to describe things (like stream
ciphers) in these terms.
JM
------------------------------
Date: Thu, 07 Dec 2000 11:48:09 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Paul Pires wrote:
> lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Bob Silverman writes:
> > > Fortunately, no one cares what you expect. I suggest you do
> > > the arithmetic to see exactly how fast a computer would need
> > > to be to break a 128-bit key in reasonable time.
> >
> > Futurist Eric Drexler projects the capabilities of mature nanotechnology
> > in his book Nanosystems. "[A] 1000 MIPS computer can occupy less than
> > one cubic micron and consume less than 0.1 microwatt of power" (page 19).
> > One cubic kilometer of such devices executes 2^120 instructions per
> > second.
>
> Hmmmm. A one cubic meter "computer" contains 10^18th mini's? Burns 10^11th
> Watts? Might get a little warm.
> Estimates of computing power growth ALWAYS
> fail to querry the packaging guy. Maybe a physics buff can tell us if this is
> less
> energy density than that of our sun.
The human body produces about one watt per pound. The Sun produces less than
this. Since the Sun has a density below unity (it would float) it also produces
less energy per unit volume.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Fips Pub 140-1 and RNG
Date: Thu, 07 Dec 2000 16:37:12 GMT
> Random numbers are often required for "Power On Self-Test"s (POSTs).
> Could that have been what the document was talking about?
It was indeed. What difference does it make whether these tests are
executed on power up as opposed to being executed at any other time ?
Brice.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Stanley Chow <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Thu, 07 Dec 2000 17:02:48 GMT
Matt Timmermans wrote:
>
> A company called Cloakware seems to claim that they could protect software
> that decrypts, making it infeasible to extract the key being used. It's
> hard to believe, but their Web site makes it sound plausible:
>
> http://www.cloakware.com/
Thanks for the plug, Matt.
Yes, we even have a demo package in Java, the class file can decrypt and
encrypt with a key that is embedded in the class file. You can run the
program to verify that actual DES is done. This demo package is
available
under NDA. (And to pre-answer the question - yes we know how to extract
the key, a real person has cracked it as well; but the new version that
we are working on will have much improved security.)
As long as I am saying stuff, I might as well mention that we don't just
hide keys in S/W, we make general S/W secure. Some more information are
available on my web-site, but really interesting info will require an
NDA. (And yes, we know about ICE, emulators, and cool reverse
engineering
tools and hacking toys. We still think we know how.)
> This wouldn't work for DVDs, though, because the key in question has to be
> transmitted to the DVD player, and this can be intercepted.
There are many interesting application including DVD-like stuff. Indeed,
if
DVD had used our technology, it would have taken much longer for DeCSS
to
be produced.
--
Stanley Chow C.T.O. [EMAIL PROTECTED]
Cloakware Corp (613) 271-9446 x 223
------------------------------
** 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
******************************
