Cryptography-Digest Digest #274, Volume #13 Tue, 5 Dec 00 10:13:01 EST
Contents:
Re: cracking a char subst cypher (Tom St Denis)
Re: Why Galois Fields in Cryptography? (Tom St Denis)
Re: MD5 byte order (Paul Schlyter)
Re: Why Galois Fields in Cryptography? (Mok-Kong Shen)
Re: ARCFOUR (RC4) used for CipherSaber-N (Punchy)
Re: RC4 or Rijndael (Guy Macon)
Re: MD5 byte order (Thomas Pornin)
DES and Salt ("Mike The Man")
Re: Why Galois Fields in Cryptography? (Erwann ABALEA)
Re: Fips Pub 140-1 and RNG (DJohn37050)
Re: MD5 byte order ("Brian Gladman")
Re: Why Galois Fields in Cryptography? (Arturo Magidin)
Re: MD5 byte order (Erwann ABALEA)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: cracking a char subst cypher
Date: Tue, 05 Dec 2000 13:03:41 GMT
In article <[EMAIL PROTECTED]>,
Frank Hsueh <[EMAIL PROTECTED]> wrote:
> I was just wondering... is there any code out there to crack a simple
> character substitution cypher?
Like a monoalphabetic substitution cipher? Not too hard. You look for
matching frequencies of characters (between a sample of original
language and the ciphertext) and try to match up characters. It's a
bit of math/muddle but often can be done easily if the ciphertext is
long enough.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Galois Fields in Cryptography?
Date: Tue, 05 Dec 2000 13:11:56 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> The new Advanced Encryption Standard, Rijndael, makes use of
> arithmetic in GF(2^8). So did Twofish, one of the other finalists in
> the AES process.
>
> Not being terribly up on advanced math, I wondered why this relatively
> unfamiliar type of operation was used in these block ciphers. I
> realize that exotic math is needed for public-key algorithms, but
> surely prosaic things like addition, XOR, table-lookup, and so on seem
> to be enough for many block ciphers.
GF(2^w) math was also used in Square before the AES fianalists. Using
a Galois Field based on a polynomial basis is actually not that hard to
work with. It can be used for first order decorrelation (i.e
DFC/COCONUT) as well.
> However, in a thread (on sci.crypt) titled "The Next Step After OTP",
> I considered one intrinsic weakness of the one-time-pad and certain
> other stream ciphers - those which simply XOR the output of a
> pseudo-random number generator with the plaintext - the fact that one
> can XOR a pattern of bits with the ciphertext, with the certain result
> that one has changed the plaintext in the corresponding way. This is
> called the "bit-flipping" attack, and essentially the same thing can
> be done if modulo-n addition for n larger than 2 replaces XOR.
I fail to understand how anyone could say "weakness of the otp". It's
the perfect cipher (security wise).
> they can be met, for an alphabet of N symbols, if the keystream
> consists of symbols from a set of N(N-1) symbols, that determine two
> quantities, A (having N values) and B (having N-1 values) where the
> encipherment operation is: (plain * B) + A = cipher, where * and + are
> the operators for a finite field of order N.
This won't work in GF(2^w) for two reasons. 1) If plain is zero then
A is known. (i.e cipher = A). 2) Vice versa for B. So in a chosen
plaintext attack this cipher is completely weak. In a known plaintext
attack 1/256 ciphertext bytes will directly leak the internal state.
You should use Z257 instead since you can map 0..255 to 1..256 and not
have any strict identities.
> And so, if one wishes to encrypt a binary data stream eight bits at a
> time, this attractive property is therefore attained by means of
> GF(2^8).
>
> Which gives one reason _why_ one might see Galois Fields in use for
> cryptographic purposes. I've now added a page to my web site at
>
> http://home.ecn.ab.ca/~jsavard/crypto/co041103.htm
There are many more then just this one reason:
1. New algebraic structure. Mix it with Zp operations...
2. Allows for MDS matrices (i.e the coefficients are from GF(2^w))
3. Allows the construction of LFSRs
4. Allows the construction of first order decorrelation modules
5. Allows fast ECC routines
6. Allows the construction of really good sboxes (inversion and cubing)
> containing the material from that thread, at which people are invited
> to look and tell me if I'm making sense or if I'm all wet.
I would suggest you actually play with the math first. If you're any
decent at C programming I could forward some routines if you like. In
fact my website has a few (GFmath.c and goodbox.c) routines you could
look at.
Tom
http://www.geocities.com/tomstdenis
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: MD5 byte order
Date: 5 Dec 2000 14:00:40 +0100
In article <90ic57$255k$[EMAIL PROTECTED]>,
Thomas Pornin <[EMAIL PROTECTED]> wrote:
> According to Bob Luking <[EMAIL PROTECTED]>:
>> But I cannot tell whether to seed A, for example, with the word 67452301 or
>> the word 01234567.
>
> The RFC 1321, which describes MD5, specifies the ordering of bytes; see
> paragraph 3.3:
>
> <<
> A four-word buffer (A,B,C,D) is used to compute the message digest.
> Here each of A, B, C, D is a 32-bit register. These registers are
> initialized to the following values in hexadecimal, low-order bytes
> first):
>
> word A: 01 23 45 67
> word B: 89 ab cd ef
> word C: fe dc ba 98
> word D: 76 54 32 10
> >>
>
> "low-order bytes first" means that A is 0x67452301, B is 0xefcdab89, etc...
>
>
> Those endianness things are infortunate, because in MD5 they are mixed:
> bytes are represented with the low-order byte first, but, inside a byte,
> the bits are in big-endian form: the most significant bit is first.
Excuse me, but how on Earth do you determine the "bit order within a byte"?
The "byte order within a word" is determined by the addresses: if the ordering
is little-endian, then the least significant byte occupies the lowest byte
address within the word (and the other way for big-endian).
Now, you claim "inside a byte, the bits are in big-endian form",
which would imply that the most significant bit within the byte have
the lowest bit address. Now, if it has the lowest bit address, individual
bits must have their own bit addresses.
Thus, you must be using a bit-addressable computer. Which computer
(brand, model, version, etc) are you using? All computers I have
been using have NOT been bit-addressable (except a few embedded
systems on credit-card sized "smartcards", where individual data bits
indeed were individually addressable). Thus you must either be using
some very unusual kind of computer -- or else you're confusing
matters. On almost all computers, the byte (or, on some older
computers, the word) are the smallest addressable unit: if you want
to fetch data, you must read at least a byte (or, on some older
computers, a word). If you want to get at an individual bit, you
must read the byte (or word) containing that bit, and then mask and
shift it out. Therefore it's pointless to talk about the "bit order
within a byte": all bits are read in parallell, not serially.
On an RS-232 connection though, bits are sent serially, so there you
can indeed talk about "bit order in a byte" in a meaningful way.
AFAIR the lowest-ordered data bit is sent first (immediately after
the Start Bit), thus in RS-323, bytes are "little-endian". Other
serial protocols may of course be "big-endian" -- it's up to the UART
to determine the "endian-ness" of the bytes.
Regarding Smart-cards (i.e. those credit-card sized chip-cards), both
varieties exist: some smartcards are little-endian, others are
big-endian. Still others (the simplest ones) don't even define bytes
at all but merely considers memory as an array of bits, to be read
individually, as many as you need, with no regard to any "bytes".
I mentioned that some older computers are word-addressable only: the
smallest data unit to be read on such a computer is the word. If you
want to get at an individual byte, you must read the word containing
that byte, and then mask and shift out the byte you want to get at.
Naturally, such computers are inefficient at text processing --
they're more suitable for number-crunching, and are nowadays quite
uncommon. Yet, on those word-addressable computers, it's pointless
to try to define the "byte order within a word" as "little-endian" or
"big-endian", for the simple reason that individual bytes aren't
addressable on these computers.
> The SHA-1 and SHA-256/384/512 specs are more coherent: they use
> big-endian everywhere.
:-) ...even if the data is transferred over an RS-232 line? <g>
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Galois Fields in Cryptography?
Date: Tue, 05 Dec 2000 14:44:15 +0100
John Savard wrote:
>
> The new Advanced Encryption Standard, Rijndael, makes use of
> arithmetic in GF(2^8). So did Twofish, one of the other finalists in
> the AES process.
>
> Not being terribly up on advanced math, I wondered why this relatively
> unfamiliar type of operation was used in these block ciphers. I
> realize that exotic math is needed for public-key algorithms, but
> surely prosaic things like addition, XOR, table-lookup, and so on seem
> to be enough for many block ciphers.
>
> However, in a thread (on sci.crypt) titled "The Next Step After OTP",
> I considered one intrinsic weakness of the one-time-pad and certain
> other stream ciphers - those which simply XOR the output of a
> pseudo-random number generator with the plaintext - the fact that one
> can XOR a pattern of bits with the ciphertext, with the certain result
> that one has changed the plaintext in the corresponding way. This is
> called the "bit-flipping" attack, and essentially the same thing can
> be done if modulo-n addition for n larger than 2 replaces XOR.
>
> Naturally, there are other solutions to this problem, involving
> one-way hash functions, that are used in practice, but I thought it
> was interesting theoretically to see what would be the _minimum_
> requirement to make a cipher that behaved like a stream cipher which
> provided a different rearranged substitution alphabet for every symbol
> enciphered. It is easy enough to produce a cipher like that if one is
> willing to be elaborate and complicated; a rotor machine simulation is
> one possibility, but what is the minimum condition?
>
> It turns out that if the conditions are explicitly stated as follows:
>
> the keystream symbols have to have the properties needed for a
> one-time-pad, and furthermore
>
> when a corresponding plaintext and ciphertext symbol are known,
> changing the ciphertext symbol to any one of the other possible values
> must have the result that all the plaintext symbols (except the known
> one) must be equally likely
>
> they can be met, for an alphabet of N symbols, if the keystream
> consists of symbols from a set of N(N-1) symbols, that determine two
> quantities, A (having N values) and B (having N-1 values) where the
> encipherment operation is: (plain * B) + A = cipher, where * and + are
> the operators for a finite field of order N.
>
> And so, if one wishes to encrypt a binary data stream eight bits at a
> time, this attractive property is therefore attained by means of
> GF(2^8).
>
> Which gives one reason _why_ one might see Galois Fields in use for
> cryptographic purposes. I've now added a page to my web site at
>
> http://home.ecn.ab.ca/~jsavard/crypto/co041103.htm
>
> containing the material from that thread, at which people are invited
> to look and tell me if I'm making sense or if I'm all wet.
The following are my humble comments and experts may
correct me.
In Rijndael the 1/x mapping in GF happens by chance to
be a good substitution in terms of bit diffusion and
simultaneously to have a simple succint mathematical
description (i.e. to describe the same in Z_n is more
complicated). GF isn't by itself magic, except for the
property that all non-zero elements have inverses.
Exactly that has Rijndael exploited to give a very simple
description of its substitution.
As to your OTP issue, I certainly have not fully understood.
But I have a point: One can group the bits of that sequence,
say 8 bits (byte) for the case corresponding to an alphabet
of size 256, and use them as keys to a sufficiently large
polyalphabetic substitution table, i.e. somewhat more columns
than 256 but not necessarily extremely large, where each
column is an arbitrary random permutation of the alphabet.
Would such a scheme serve well your purposes?
I also have a probably very trivial question: The expression
ax+b is a linear one. Now this evaluated in GF is certainly
not linear in Z_n and vice versa. So, one has to be very
careful when talking about the advantages/disadvantages
of linearity in crypto, isn't it? (In other words, what are
the disadvantages of linearity, when the context of where
the expression is evaluated is not given?)
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Punchy)
Subject: Re: ARCFOUR (RC4) used for CipherSaber-N
Date: Tue, 05 Dec 2000 14:03:12 GMT
Yeah, it looks like you've got it right on the key stirring part.
Nice implementation. I've never seen a VB version of RC4.
On Thu, 30 Nov 2000 16:27:44 GMT, [EMAIL PROTECTED] (Glide) wrote:
>Hi Cryptoids. If any of you are familiar with the CipherSaber
>implementation of RC4 and you would care to enlighten me, I'd
>appreciate it. Since I do my thing in Visual Basic, it will look
>fairly different from the usual suspects (C code).
>
>If you are so inclined, please comment to this here in the newsgroup
>since my e-mail address is fraudulent.
>
>I use a Visual Basic version of ARCFOUR. I tried it against
>thevectors that were published with "alleged RC4" and it passes. I
>added support for CipherSaber (part of which will not show in the
>following code) and would like to correctly implement CipherSaber-n
>where n is the number of times you mix the key. I'm not sure I'm
>doing it in the right spot. If you wouldn't mind, would you comment
>on where I propose to mix the key "n" times? Here is the code:
>
>' *** Begin ARCFOUR Function ***
>
>Public Function ARCFOUR(inp As String, key As String) As String
>
>Dim S(0 To 255) As Byte, K(0 To 255) As Byte, i As Long
>Dim j As Long, temp As Byte, Y As Byte, x As Long, z as long
>Dim Outp As String
>Dim n as long
>
>' Array/S-box is setup for ARCFOUR
>
>For i = 0 To 255
> S(i) = i
>Next
>
>j = 1
>For i = 0 To 255
> If j > Len(key) Then j = 1
> K(i) = Asc(Mid(key, j, 1))
> j = j + 1
>Next i
>
>' end of setup
>
>
>'*** This is where I'm mixing the key "n" times
>'*** If n = 1 then it is standard CipherSaber
>'*** This example shows CipherSaber-2
>
>'*** beginning of part 1 of added code
>n = 2
>For z = 1 to n
>'*** end of part 1 of added code
>
>
>' This is where I believe the key is mixed for ARCFOUR
> j = 0
> For i = 0 To 255
> j = (j + S(i) + K(i)) Mod 256
> temp = S(i)
> S(i) = S(j)
> S(j) = temp
> Next i
>
>' end of key mixing
>
>
>'*** beginning of part 2 of added code
>Next z
>'*** end of part 2 of added code
>
>
>
>' encryption part of ARCFOUR
>
>i = 0
>j = 0
>For x = 1 To Len(inp)
> i = (i + 1) Mod 256
> j = (j + S(i)) Mod 256
> temp = S(i)
> S(i) = S(j)
> S(j) = temp
> t = (S(i) + (S(j) Mod 256)) Mod 256
> Y = S(t)
>
> Outp = Outp & Chr(Asc(Mid(inp, x, 1)) Xor Y)
>Next
>
>' end of encryption
>
>ARCFOUR = Outp
>
>End Function
>
>' *** End ARCFOUR Function ***
>
>*** Important *** - This code does not show generation or handling
>of the CipherSaber ten-byte vector which is appended to the key and
>will be prepended to the encrypted data.
>
>Thank you.
>
>Glide
>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: RC4 or Rijndael
Date: 05 Dec 2000 14:23:08 GMT
Benjamin Goldberg wrote:
>
>
>Guy Macon wrote:
>>
>> Bill Unruh wrote:
>>
>> >Yes, RC4 is a stream cypher. The key can never be reused or the
>> >strength is essentially zero. It is very easy to code, and is much
>> >faster. However it is totally useless unless you can choose a random
>> >key each use. (eg, by sending the key via RSA).
>>
>> Huh???
>>
>> I use the ciphersaber [1] implementation of ARCFOUR [2] with the same
>> secret passphrase every time. There are additional random bytes that
>> are needed to avoid key reuse, but those are sent in the clear by
>> being prepended to the ciphertext. There is no need to send a key
>> via RSA or any other method.
>
>Guy, you obviously don't know what Bill's trying to do. Bill's sending
>a message, encrypted, to a person whose public key he knows, but with
>whom he does not share a private key.
Ah. I missed that. Clearly, one cannot do that with ARCFOUR, because
of the lack, of a shared secret. Thus, he must either send his
message encrypted with a public key method, or send a shared secret
and then use something like ARCFOUR. My apologies for missing that.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: MD5 byte order
Date: 5 Dec 2000 14:34:34 GMT
According to Paul Schlyter <[EMAIL PROTECTED]>:
> Excuse me, but how on Earth do you determine the "bit order within a byte"?
The MD5 specification states that it applies on a stream of bits, not
bytes. Therefore the ordering relates to bits, not bytes. You can see,
for instance, that the padding is done by appending some bits, including
the size, in bits (not bytes) of the stream. There are more and more
devices that output data bit by bit, in many areas, so the "byte" is not
a relevant notion.
Besides, not all computers use 8-bit bytes; for instance, the PDP-11
used 9-bit bytes. Interoperability issues imply that you specify clearly
what happens there.
And, last but not least, all PC since the 80386, and including all
species of pentium, are bit-adressable, using the instructions bt, btc,
btr, bts, bsf and bsr.
> > The SHA-1 and SHA-256/384/512 specs are more coherent: they use
> > big-endian everywhere.
>
> :-) ...even if the data is transferred over an RS-232 line? <g>
The way the data is transferred is irrelevant. SHA* operate on an
ordered stream of bits, regardless of the way these are represented
in whatever support is used. The usual way of doing, when using a
byte-oriented computer, is to store bits 8 at a time in each byte, the
first bit representing the high-order bit of the byte. This is just a
convention that is outside the scope of the specification.
By the way, if you write down, in binary, an 8-bit value, you just add
an ordering of bits: if I write 182, I will write it 10110110, not
01101101; this is big-endian since I read it from left to right.
--Thomas Pornin
------------------------------
From: "Mike The Man" <[EMAIL PROTECTED]>
Subject: DES and Salt
Date: Tue, 5 Dec 2000 15:44:55 +0100
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.
>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.
Could anyone tell me, if this is right?
/Mike the Man
------------------------------
From: Erwann ABALEA <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Galois Fields in Cryptography?
Date: Tue, 05 Dec 2000 14:40:47 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> However, in a thread (on sci.crypt) titled "The Next Step After OTP",
> I considered one intrinsic weakness of the one-time-pad and certain
A weakness in the OTP? Maybe in an implementation of it, but not on the
algorithm itself...
> other stream ciphers - those which simply XOR the output of a
> pseudo-random number generator with the plaintext - the fact that one
OTP states that the random number generator shouldn't be a pseudo one...
If you choose to use a prng, then the weakness lies in your
implementation.
> can XOR a pattern of bits with the ciphertext, with the certain result
And if you choose to use a "pattern" of bits, then you're definitely not
using a OTP... You must use a stream of bits, not a pattern (a pattern
can be repeated, not a stream).
> that one has changed the plaintext in the corresponding way. This is
> called the "bit-flipping" attack, and essentially the same thing can
> be done if modulo-n addition for n larger than 2 replaces XOR.
This can effectively occur, but it can be simply avoided:
- make sure that you *never* reuse random bits that you already used
- continously transmit data, even simple 00. Since your data will be
xored with random bits, the attacker can not determine the start of
the message he wants to change
--
Erwann ABALEA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 05 Dec 2000 14:49:34 GMT
Subject: Re: Fips Pub 140-1 and RNG
These are tests that each have a probability of less than one in a million in
rejecting a good RN stream as bad. The idea is that to get thru these tests,
any error must be very esoteric.
Don Johnson
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: MD5 byte order
Date: Tue, 5 Dec 2000 14:55:24 -0000
"Paul Schlyter" <[EMAIL PROTECTED]> wrote in message
news:90ioto$2sa$[EMAIL PROTECTED]...
> In article <90ic57$255k$[EMAIL PROTECTED]>,
> Thomas Pornin <[EMAIL PROTECTED]> wrote:
[snip]
> > Those endianness things are infortunate, because in MD5 they are mixed:
> > bytes are represented with the low-order byte first, but, inside a byte,
> > the bits are in big-endian form: the most significant bit is first.
>
> Excuse me, but how on Earth do you determine the "bit order within a
byte"?
This is determined by the relationship between byte or bit numbering and the
numeric significance one byte or bit to to the next. Hence if numeric
significance grows with a growing byte or bit number then it is
little-endian whereas if numeric significance decreases with growing byte or
bit number it is big-endian.
> The "byte order within a word" is determined by the addresses: if the
ordering
> is little-endian, then the least significant byte occupies the lowest byte
> address within the word (and the other way for big-endian).
Least "significant" is an ordering on the relative numeric values attached
to entities and will apply to bits as much as it does to bytes.
> Now, you claim "inside a byte, the bits are in big-endian form",
> which would imply that the most significant bit within the byte have
> the lowest bit address.
Correct - a big endian numbering of bits would make bit 0 = 128, bit 1 = 64,
... , bit 7 = 1, remembering that this is about the numeric significance
attached to entities.
Interestingly the big-endian MC68k got this almost right but chickened out
on bit numbering by numbering its bits from the least significant end of its
words. When bit field instructions were added they then went to the 'right'
big-endian bit numbering for these fields but a numbering that did not match
the numbering used for other instructions (I am doing this from memory but I
think this is correct).
Brian Gladman
------------------------------
From: [EMAIL PROTECTED] (Arturo Magidin)
Crossposted-To: sci.math
Subject: Re: Why Galois Fields in Cryptography?
Date: 5 Dec 2000 14:56:17 GMT
In article <90ipip$v9t$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (John Savard) wrote:
[.snip.]
>> However, in a thread (on sci.crypt) titled "The Next Step After OTP",
>> I considered one intrinsic weakness of the one-time-pad and certain
>> other stream ciphers - those which simply XOR the output of a
>> pseudo-random number generator with the plaintext - the fact that one
>> can XOR a pattern of bits with the ciphertext, with the certain result
>> that one has changed the plaintext in the corresponding way. This is
>> called the "bit-flipping" attack, and essentially the same thing can
>> be done if modulo-n addition for n larger than 2 replaces XOR.
>
>I fail to understand how anyone could say "weakness of the otp". It's
>the perfect cipher (security wise).
I suspect the key is in the explanationhe gives, which states that the
one-time pad in this case is given by a "pseudo-random number
generator." A true one-time pad requires a random output. If you
implement it with a pseudo-random number generator, then a
cryptographic attack on the generator may break the pad.
======================================================================
"It's not denial. I'm just very selective about
what I accept as reality."
--- Calvin ("Calvin and Hobbes")
======================================================================
Arturo Magidin
[EMAIL PROTECTED]
------------------------------
From: Erwann ABALEA <[EMAIL PROTECTED]>
Subject: Re: MD5 byte order
Date: Tue, 05 Dec 2000 14:47:12 GMT
In article <90ioto$2sa$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Schlyter) wrote:
> Thus, you must be using a bit-addressable computer. Which computer
> (brand, model, version, etc) are you using? All computers I have
> been using have NOT been bit-addressable (except a few embedded
> systems on credit-card sized "smartcards", where individual data bits
> indeed were individually addressable).
That's only on memory cards, not microprocessor cards.
Microprocessor cards can have their own bit-order, but they're not
bit-addressable: you must send bytes, not only bits.
> Regarding Smart-cards (i.e. those credit-card sized chip-cards), both
> varieties exist: some smartcards are little-endian, others are
> big-endian. Still others (the simplest ones) don't even define bytes
> at all but merely considers memory as an array of bits, to be read
> individually, as many as you need, with no regard to any "bytes".
Again, those that you describe as not having any bytes are memory cards.
Incidentally, memory cards are bit-addressable, but don't define any
bit-order. On the counterpart, microprocessor cards are not
bit-addressable, but define a bit-order.
--
Erwann ABALEA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -
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
******************************
