Cryptography-Digest Digest #518, Volume #12 Wed, 23 Aug 00 20:13:00 EDT
Contents:
Re: blowfish problem ("Kelsey Bjarnason")
Re: blowfish problem (Kaz Kylheku)
Re: Secret-sharing algorithm ([EMAIL PROTECTED])
DeCSS ruling -- More ("David C. Barber")
Re: The DeCSS ruling (Joseph Reuter)
Re: The DeCSS ruling (Jim Steuert)
Re: Steganography vs. Security through Obscurity (David A Molnar)
Re: Testvectors for DES and 3xDES (Richard Outerbridge)
Re: blowfish problem ("Kelsey Bjarnason")
Re: Stream Cipher/PRBG idea. (Benjamin Goldberg)
Re: The DeCSS ruling (Mr. I. N. Oakley)
Re: What is required of "salt"? (David Hopwood)
Re: SHA-1 program (cool!) (David Hopwood)
----------------------------------------------------------------------------
From: "Kelsey Bjarnason" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Wed, 23 Aug 2000 22:06:51 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Kelsey Bjarnason wrote:
> > We don't. However, we cannot blithely assume that char "precisely"
> > fits a byte ...
>
> It is not a "blithe assumption". It is embedded in the use of
> those terms in the C standard, which I helped write.
Okay - now, I'm working off a draft, rather than the final standard (shame,
shame, I know)... but I still haven't found anything to actually
substantiate this. I'm still looking, but so far, no good. All I've found
is that a char fits _in_ a byte; nothing about a char _precisely_ fitting a
byte - not even by implication. As I said, I may have simply missed it, but
so far, it's not been pointed out where the standard actually comes out and
makes this point.
> that approach and affirmed that insofar as the C standard is
> concerned, "byte" and "char" refer to the same thing,
Yet, as far as I can tell, that's not the case, at least from the body text.
> > Now, where does the standard actually state that chars "precisely"
> > fit bytes?
>
> Under the spec for the sizeof operator.
Well, let's see. From a draft dated 18/99...
6.5.3.4 The sizeof operator
[#2] The sizeof operator yields the size (in bytes) of its
operand, which may be an expression or the parenthesized
name of a type. The size is determined from the type of the
operand. The result is an integer. If the type of the
operand is a variable length array type, the operand is
evaluated; otherwise, the operand is not evaluated and the
result is an integer constant.
[#3] When applied to an operand that has type char, unsigned
char, or signed char, (or a qualified version thereof) the
result is 1. When applied to an operand that has array
type, the result is the total number of bytes in the
array.75) When applied to an operand that has structure or
union type, the result is the total number of bytes in such
an object, including internal and trailing padding.
Nope; neither of those do it. #2 refers to the size "in bytes"; if a
"byte" on the implementation is 16 bits, but a char 8, the implementation is
still free to refer to both as having size 1. #3 simply defines
sizeof(char) as 1. Neither actually addresses the issue. Nor do any of the
other numbered sections under this heading.
Okay, so maybe something changed in the final standard. I still don't see
anything that says an implementation cannot have a 16-bit byte and an 8-bit
char, as long as sizeof regards chars as units (sizeof char == 1 ).
Or maybe you meant a different section? This would seem to be the section
you meant, but I don't see how - unless the final standard actually fixed
this section - this actually resolves to the conclusion that a char
precisely fits a byte.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Reply-To: [EMAIL PROTECTED]
Date: Wed, 23 Aug 2000 22:03:03 GMT
On Wed, 23 Aug 2000 20:49:27 GMT, Kelsey Bjarnason <[EMAIL PROTECTED]>
wrote:
>Now, where does the standard actually state that chars "precisely" fit
>bytes?
The C99 draft has this text:
Values stored in objects of any other object type consist
of n×CHAR_BIT bits, where n is the size of an object of that
type, in bytes. The value may be copied into an object of
type unsigned char [n] (e.g., by memcpy); the resulting
set of bytes is called the object representation of the value.
In other words there is a correspondence between unsigned chars and bytes,
and an array of unsigned char can record the representation of the value
of any object.
By aliasing an object as such an array, all of its bits are available,
including any gaps, such as unused bits in the representation of some
types, gaps between structure members and padding at the end of structores.
Also, take a look at the definition of the memcpy() function:
The memcpy function copies n characters from the object pointed
to by s2 into the object pointed to by s1.
The terms ``character'' and ``byte'' are used interchangeably in many places.
(But ``character'' and ``char'' do not mean the same thing).
Another bit of text which indicates that unsigned char, at least, must not have
any unused bits in its representation is the following:
6.2.6.2 Integer types
[#1] For unsigned integer types other than unsigned char,
the bits of the object representation shall be divided into
two groups: value bits and padding bits (there need not be
any of the latter).
In other words, unsigned integer types may have padding bits, but unsigned
char must not have any. It uses all the available bits in the underlying byte.
Signed chars, on the other hand, could have padding bits; there is no
prohibition against that. However, in portable programming, you would not use
signed or plain chars for manipulating bytes, so the issue in the imaginary C
implementation would not arise. In your example that I snipped, if the C
program used unsigned char, then it would be be able to access all 16 bits of
each byte produced by the Pascal program. If it used char or signed char to
try to do that, then it would be a broken program. Consider that on platforms
with two representations for a signed zero, the type signed char cannot record
the value of a byte even if it has no padding bits. In the course of
evaluation, the value 0 can change from one representation to another, so even
copying objects as arrays of signed char is not reliable.
The type char is only suitable for manipulating characters in the translation
character set and for communicating with standard library interfaces which use
char.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Secret-sharing algorithm
Date: Wed, 23 Aug 2000 22:13:41 GMT
Hi Tom,
Thanks for the reply.
>
> Why not ditch 3-5 and just do this
>
> 3. Client sends server K1 which is encrypted using the servers public
> key.
>
I was wondering about this... If the key is totally dependent on the
client, doesn't this introduce the ability for replay attacks? I'm
trying to model SSL a bit, and they use unencrypted random data from
both the server and the client to generate the final key, along with
a client-only-generated premaster key.
> > Is this method secure? I know that the "one-time" pad isn't quite
> > really a one-time pad, but it's good enough, isn't it? Also, assume
> > that the random data will be around 40-64 bytes in length.
>
> Why so much? Just use a 256 bit key encrypted with the PK crypto.
SSL seems to send over random data thats 48 bytes in length. I think
what eventually happens is that keys are generated by taking some MD5
hash of the master key. I think this is what they're doing, but I'm not
too sure. As you can see, I'm not too confident about the actual theory
behind it, but I'm just trying to copy an existing standard...
> > As a side note, I plan on expiring both the symmetric keys and the
> > server's public key every 1 hour or so.
> >
> > Any glaring flaws?
>
> Ya, um making a key every hour could be a pain in the royal behind.
>
> And the symmetric key should expire as soon as the communication is
> finished, not every hour.
>
Oh yeah, I meant that the keys would expire the earlier of 1 hour or the
end of a connection... Also, is regenerating keys every hour that big
of a pain? I haven't tested this out yet, so I'm not sure!
Thanks for your help!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: DeCSS ruling -- More
Date: Wed, 23 Aug 2000 15:36:50 -0700
What was astonishing (showing the judge's lack of understanding) is when you
read the judge's ruling. In the first couple of paragraphs the judge refers
to CSS as a Copy Protection Scheme.
As anyone here should know, CSS does *not* prevent copying. You can make as
many image copies as you want (or given the high price of DVD-RW, as many as
you can afford :^). The encrypted file may be copied as many times as you
wish, giving perfect digital, encrypted copies down to the n-th generation.
And all of these copies play back just the same in licensed players.
CSS IS NOT COPY PROTECTION!
And the judge clearly doesn't get it.
Yeah, it's frustrating, since the whole ruling is that DeCSS is in violation
of the DMCA because it breaks copy protection, when it does no such thing.
*David Barber*
------------------------------
From: Joseph Reuter <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: Wed, 23 Aug 2000 15:51:00 -0700
"Douglas A. Gwyn" wrote:
>
> Jim Steuert wrote:
> > To presume that we are reverse-engineering software for the purpose
> > of some "illegal" intent "before" we actually reverse-engineer it
> > is a very serious presumption of guilt.
>
> I didn't say that.
> However, the usual purpose of reverse-engineering is to benefit
> from somebody else's work without compensating them for it.
I do a lot of reverse-engineering to figure out the undocumented
(or poorly-documented) interface to something so that I can
communicate with it.
--
Joseph A. Reuter, Wizard-in-Training [EMAIL PROTECTED]
"Olorin I was in my youth in the West that is forgotten."--Tolkien
You can't win, you can't break even, and it's the only game in town.
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: Wed, 23 Aug 2000 19:12:14 -0400
Reply-To: Jim, Steuert
Thanks,
That is very helpful.
-Jim Steuert
Gisle Sælensminde wrote:
> In article <[EMAIL PROTECTED]>, Jim Steuert wrote:
> >
> >Yes, I got a copy some time ago (before it was illegal to post
> >it). Although
> >I didn't study it yet, now I am very curious about it.
> >
> >Can anyone in this group explain the code (with annotations). I
> >really am
> >curious as to why it is breakable. Perhaps posting it with
> >annotations but
> >without the keys would allow us to understand the algorithm and
> >steer us
> >away from making that same mistake again. Is that legal? If not,
> >then maybe
> >a legal description of that algorithm or family of algorithms
> >exists
>
> DeCSS was made by breaking keys brute force, and is not that
> interesting. It is probably more interesting to read the
> cryptanalysis of CSS, that was published after DeCSS was
> released.
>
> http://people.a2000.nl/mwielaar/dvd-css/csspaper/css.html
>
> --
> Gisle Sælensminde ( [EMAIL PROTECTED] )
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going
> to land, and it could be dangerous sitting under them as they fly
> overhead. (from RFC 1925)
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Steganography vs. Security through Obscurity
Date: 23 Aug 2000 23:09:37 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
> on Information Hiding which have been going on for the last few years.
> Christian Cachin also has an "Information-Theoretic Model for
> Steganography" up on eprint.iacr.org (if memory serves), which attempts
> to sort out these questions.
a web pointer for Cachin's paper : http://citeseer.nj.nec.com/did/114788
also see the references.
As to the other question - "what kind of security can we get from
watermarking schemes?" that seems to depend critically on just
what is *meant* by a watermarking scheme. (can everyone read it?
can only one person read it? how resistant to change should it be?)
Something I'm not competent to discurse on without taking time
to review different kinds of schemes and their discussion. time which I
don't have right now. but there are some papers in the references of
the above URL on such things as "the limits of steganography" and
"attacks and counterattacks for watermarking."
-David
------------------------------
From: Richard Outerbridge <[EMAIL PROTECTED]>
Subject: Re: Testvectors for DES and 3xDES
Date: Wed, 23 Aug 2000 19:30:45 -0400
=====BEGIN PGP SIGNED MESSAGE=====
2000-08-23 19:27:44 EDT
These should get you started.
outer
In article <8nvvoo$9ak$[EMAIL PROTECTED]>, "kihdip"
<[EMAIL PROTECTED]> wrote:
>Has somebody knowledge of a site with testvectors for DES and 3xDES ??
>
>Thanks
>Kim
/* Validation set:
*
* Single-length key, single-length plaintext - 1-key, 1-DES
* Key : 0123 4567 89ab cdef
* Plain : 0123 4567 89ab cde7
* Cipher : c957 4425 6a5e d31d
*
* Double-length key, single-length plaintext - 2-key, 3-DES
* Key : 0123 4567 89ab cdef fedc ba98 7654 3210
* Plain : 0123 4567 89ab cde7
* Cipher : 7f1d 0a77 826b 8aff
*
* Triple-length key, single-length plaintext - 3-key, 3-DES
* Key : 0123 4567 89ab cdef fedc ba98 7654 3210 89ab cdef 0123 4567
* Plain : 0123 4567 89ab cde7
* Cipher : de0b 7c06 ae5e 0ed5
*
* des3_C.c
*/
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.1i
iQEVAwUBOaReg0JrWteExW9jAQGdCwgAoYtQxr5Dp5/8euqdmNFnFUQS5l4Qwk05
nSiWyRePrpQ7kLWK5hCyOmocv2ufB0ffp8B3WXF5XtDEmY1Y+EMIFKjZaNG4B21b
Xe2G6JS0Dbju6GMAbZY25gDCrggMiqR2raix6eLVLYSQA95ZMQ7smbhEcqJP6OYt
uXesWLcQHVbrM908MGK8NpZGvj4HUnX7rq6KDhqUr/qg25sTYeqBr7u0KLzxzyIW
WEToewWc9+erQ93EKIXWmxcEXUxLC7lbK5Kqmdtmc0K3YYMTzEUv3f/qDdzg9Grp
WEBx0o72E4VUVbSxaJgymQ4SXJ7aU42hLzTWIPa+qXhOBxEtAeSbIg==
=lay2
=====END PGP SIGNATURE=====
--
<[EMAIL PROTECTED]> :
Just an "eccentric soul with a curiosity for the bizarre".
Payloads to: A902/MCE307/3/17TPU-28413618 (or thereabouts)
------------------------------
From: "Kelsey Bjarnason" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Wed, 23 Aug 2000 23:35:09 GMT
"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 23 Aug 2000 20:49:27 GMT, Kelsey Bjarnason
<[EMAIL PROTECTED]>
> wrote:
> >Now, where does the standard actually state that chars "precisely" fit
> >bytes?
>
> The C99 draft has this text:
>
> Values stored in objects of any other object type consist
> of n×CHAR_BIT bits, where n is the size of an object of that
> type, in bytes. The value may be copied into an object of
> type unsigned char [n] (e.g., by memcpy); the resulting
> set of bytes is called the object representation of the value.
>
> In other words there is a correspondence between unsigned chars and bytes,
> and an array of unsigned char can record the representation of the value
> of any object.
It says the _value_ consists of nxCHAR_BIT bits, where n is an object of
that type, in bits. So, the following can hold true:
CHAR_BIT == 8
Value = 32
Type holding value == char
That is, char val = 32; under the text above tells us that the value 32 is
represented by CHAR_BIT * sizeof(char) bits, which, in this case, is 8. So
far so good. What's the size of char in bytes? Well, on the hypothetical
implementation I'm examining, it _should_ be 0.5 - but the standards decree
that, in fact, sizeof(char) is 1. It still only occupies half the byte,
though.
Still nothing indicating that bytes and chars are, by definition or
otherwise, precisely the same size; only that chars must fit in bytes.
> By aliasing an object as such an array, all of its bits are available,
> including any gaps, such as unused bits in the representation of some
> types, gaps between structure members and padding at the end of
structores.
Ah, but again, that doesn't apply. Example:
unsigned int x = 32; /* assume 32-bit int */
unsigned char *ptr = &x;
Under my hypothetical implementation, x could be aliased by ptr, without
holes, as 4 elements: *ptr, *(ptr+1), etc. No inconsistency involved. Nor
does it yet actually even involve the underlying distinction between char
and byte.
> Also, take a look at the definition of the memcpy() function:
>
> The memcpy function copies n characters from the object pointed
> to by s2 into the object pointed to by s1.
Right; and this would continue to work inside the C program, on an
implementation such as I described.
> 6.2.6.2 Integer types
>
> [#1] For unsigned integer types other than unsigned char,
> the bits of the object representation shall be divided into
> two groups: value bits and padding bits (there need not be
> any of the latter).
>
> In other words, unsigned integer types may have padding bits, but unsigned
> char must not have any. It uses all the available bits in the underlying
byte.
No; it says except for _unsigned char_, there shall be two groups; it says
nothing about the bytes. Again, in my hypothetical implementation with
8-bit chars and 16-bit bytes, the above would still hold true.
There's an underlying assumption being made in this discussion that chars
and bytes are synonymous. That's the very assumption I'm questioning,
because I can't find a thing in the standard to support it. The problem
with an example such as you just offered is that it assumes the very thing
in question; if you assume that bytes and chars are synonymous, then
obviously, bytes can't have holes, so they must be chars. Well, if you're
assuming the equivalence in the first place, why even bother looking at
whether there are holes involved? It's unnecessary. If, however, you
assume for the moment that bytes are _not_ synonymous with chars, you'll see
first, that the lack of "holes" in a char would appear to be irrelevant, and
second, that in fact, there seems to be nothing in the standards to say that
they are, in fact, the same.
> implementation would not arise. In your example that I snipped, if the C
> program used unsigned char, then it would be be able to access all 16 bits
of
> each byte produced by the Pascal program.
No, it would not. From the example, the Pascal program could happily use
16-bit chars, but the C program cannot. As soon as fgetc() returns from
reading a byte from the file, the value returned is in the range 0..255
(i.e. the range allowed by CHAR_BIT on this implementation) or EOF. What it
manifestly is _not_ is 16 bits wide; this implementation doesn't support
16-bit chars, only 16-bit bytes.
That, again, is the kicker. Unless it is actually defined that byte and
char are synonymous, that they are, in fact, precisely the same size, you
potentially fall into this trap. No, I don't suspect there are many real
implementations such as this, but we have yet to see a single instance of
anything which states that such an implementation is non-conforming.
> If it used char or signed char to
> try to do that, then it would be a broken program. Consider that on
platforms
> with two representations for a signed zero, the type signed char cannot
record
> the value of a byte even if it has no padding bits. In the course of
> evaluation, the value 0 can change from one representation to another, so
even
> copying objects as arrays of signed char is not reliable.
Right... one wouldn't generally use char to store the result of fgetc().
Nor even unsigned char. However, as I understand it, the following is
perfectly valid:
int c;
unsigned char uc;
c = fgetc( file );
if ( c != EOF )
uc = (unsigned char) c;
At this point, the conversion from c to uc should be lossless, no? Yes;
fgetc() retrieves the next available character as an unsigned char, and
returns it converted to an int. So the above conversion is lossless.
Note that it remains lossless - from the C implementation's point of view -
even if the distinction between byte and char is maintained; the fact that
it actually loses data, because the implementation regards chars as 8 bits,
but the data coming in is doing so in 16-bit bytes, is irrelevant... except
that it means you cannot safely read any files written by any programs on
this machine other than those written by programs compiled with this
compiler.
Again, is this a stupid implementation? Sure. Is it a conforming
implementation? It would appear so - because we have _still_ not actually
determined where, if in fact anywhere, in the standard, that a byte and a
char are defined to be precisely the same size.
> The type char is only suitable for manipulating characters in the
translation
> character set and for communicating with standard library interfaces which
use
> char.
I was, admittedly, a bit sloppy there; please see above.
All things considered, though, I am still not convinced - because I've seen
no reason to regard it as true - that in fact, chars and bytes cannot be of
disparate sizes, as long as the implementation regards the size of each as
one.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Stream Cipher/PRBG idea.
Date: Wed, 23 Aug 2000 23:37:26 GMT
David A. Wagner wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > While I do know that it's a variant on a Vigenere cipher, I don't
> > know how to use O(the *sum* of the rotor lengths) bits of output to
> > crack it.
> >
> > How do I use linear algebra to break this? Keep in mind I'm not
> > really a crypto expert. If this is a well-known problem, where on
> > the web might I find a description/solution?
>
> I think you can find the techniques described in the following
> two references.
>
> A. Sinkov, {\it Elementary Cryptanalysis, A Mathematical Approach.}
> New York: Random House, 1968.
>
> B. Tuckerman, ``A study of the Vigenere-Vernam single and multiple
> loop enciphering systems,'' IBM Research Report RC2879,
> 14 May 1970, Yorktown Heights NY.
Unfortuneatly, I don't have a technical bookstore anywhere nearby... I
need online references, not books. Did I type 'on the web' with
invisible ink^H^H^Hbits?
--
"There's a mathematical reason not to trust Christians... The Buddhists
believe that human lives repeat. The atheists believe that human lives
terminate. That means that the Christians must believe that humans are
irrational."
- Matt Katinas
"Not necessarily... they could think that humans are imaginary."
- Rob Pease, in response to the above
"Of course Christians think humans are irrational: They believe humans
are transcendental, and all transcendentals are irrational. I suppose
that all we can be certain of is that humans are complex."
- Me, in response the the above
------------------------------
From: [EMAIL PROTECTED] (Mr. I. N. Oakley)
Subject: Re: The DeCSS ruling
Date: Wed, 23 Aug 2000 23:43:23 GMT
[EMAIL PROTECTED] (Gisle Sælensminde) wrote:
>The intention of this law is to allow revese engineering
>if there is sensible reason for doing so.
I think it's outrageous that there could be a law restricting you from
examining the instructions that someone else is giving to YOUR computer.
--
"Mr. I. N. Oakley" is actually 0268 359741 <[EMAIL PROTECTED]>.
01 2 3 456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
Date: Thu, 24 Aug 2000 00:45:46 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What is required of "salt"?
=====BEGIN PGP SIGNED MESSAGE=====
John Myre wrote:
> =
> I'm wondering what (cryptographic) properties "salt" has to have.
> =
> Let me begin by restricting the question to salt as used in
> password files. This might be the original Unix-style file,
> or it might be some verifier-based setup.
> =
> The main purpose of salt, as I understand it, is to ensure
> that entries for the same password aren't the same (or rather,
> that the adversary cannot tell that the entries are for the
> same password). Is there more?
An attacker can start a dictionary attack at the time when he/she
learns the salt. Therefore, the salt should be unpredictable, so
that the attack can only be started when the password file is
compromised. This point appears to have been missed in the other
replies that stated that salts only have to be unique.
It's also worth pointing out that passwords are often shared between
different systems (there seems to be no practical way to dissuade
users from doing this; I even do it myself despite knowing the risks).
So even if we don't consider the time at which a dictionary attack
can be started to be significant, salts should preferably be globally
unique, not just unique on a single system.
> Usually I see the assumption that the salt is "random". I
> don't see, however, why this is so.
The desired property is a high "guessing entropy" [1], i.e. it should
not be possible for an attacker to order the possible salts in
such a way that searching them in that order has a non-negligable
probability of success, with a feasible amount of work. This is
the same property that is needed for security of cryptographic keys
against (slightly generalised) brute force attacks.
Salts don't *necessarily* need to be strongly random in the sense
required for the output of a pseudo-random function, or the keystream
of an additive stream cipher (i.e. that each bit cannot be feasibly
predicted with probability significantly greater than 1/2, given all
the other bits). OTOH, if they are random in this strong sense, the
length of salt needed will be shorter.
> For example, what would be wrong with using a simple counter to
> generate salt values?
It is predictable; see above.
> Or, what if the salt were the concatenation of the user name
> and the server name (or address)?
Also predictable.
> Is there a reason to change the salt when we change the password?
Yes, if changing the password is intended to contribute to recovering
from a password file compromise.
Another desirable property of passphrase hashes, rather than salts, is
that they be computationally expensive (variably so, so that increases
in processor speed do not obsolete the hash), and no more cost-efficient
to calculate in a dictionary attack using special-purpose hardware, than
they are on a typical machine in normal use. (One way of attempting to
achieve the latter is to make the hash memory-intensive.)
A good overview of this is [2], which suggests two concrete passphrase
hashes based on these criteria.
[1] David Wagner,
http://www.cs.berkeley.edu/~daw/my-posts/entropy-measures
[2] Niels Provos and David Mazi=E8res, The OpenBSD Project
"A Future-Adaptable Password Scheme,"
Presented at USENIX '99.
http://www.usenix.org/events/usenix99/provos.html
- -- =
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 0=
1
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 b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOaRhuTkCAxeYt5gVAQEHxQgAuKXYLSiWjq79d1S1seQouQ3pyuFBOFM7
ZPbpBEOTpWXbfsHtTb4WCtyce3zzFVzoey/JVCuRttTWphihoSul9Apz4bCiaacm
YIUHS3eOZANpbnX8wb9StuMk3w8tH0nX+IHptKweScbxX8HZqHKvdOI+7IpTLhco
1laB6jSFiftWfn/81zUHbYEh9vAtrNWNxObc9Dd+IfaBY3HIvFC6BZJNVABMZOCE
fqzTQ1rBG6EKlkLbo+5wy6lh2OqmUF+atIBPWev87oT47sGKVQpwZI1BuNGAlJXY
0/KtO2A/gckXrfRznsifS1ZOC3gmkn9V3h0Qdj6MGsK/aap7G0nhjg=3D=3D
=3DgQtK
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 24 Aug 2000 00:46:00 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: SHA-1 program (cool!)
=====BEGIN PGP SIGNED MESSAGE=====
"S. T. L." wrote:
> [...] I took the largest darn file I had on my hard drive,
> a hulking behemoth called "pak0.pak" in the \valve\ directory of the game
> Half-Life (weighing in at a crushing 302,907,835 bytes), and the reference I
> use (HASHcipher demonstration by Bokler.com) output a different hash than my
> SHA-1 program. Something is afoot, and I'm not sure exactly what it could be.
That's more than 2^31 bits. Check that you're using unsigned integers to encode
the bit count (and when you've fixed that, check that your implementation works
for files larger than 512 MB, i.e. 2^32 bits).
- --
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
iQEVAwUBOaRRqzkCAxeYt5gVAQEcvgf8D5eijV0HDkj39pkWIwCj/BA6u8RotCf4
/ox3zaJgUJj8bzdrDeWdsF13UT2AkEcLP8qXK+CSm+G964AcpcJxelvSWWpJP4jD
Py71a4ybS23scl/fO9MPm0xNfXaNIILC+aCvGEs/J6+pftuzbwQqhDK2Mfe0pupI
z7eF+lxUpJFsGUzCQNNSNmVW5n4K4xuisOQ4/0ToPwc6jItRCJXHRBkuBe4v5ylE
KkSvwbxDCPfQVu5wc6m/1DGTMnQE6H3ZStF+zjS1ktGYvq1yPKATW/KOjvchLX56
BAlmgMyggtWffkiZgbDXXDsfcJemBT/F7tkvDQkUgVSFYkOAkks0uA==
=Vc3F
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
