Cryptography-Digest Digest #498, Volume #12 Mon, 21 Aug 00 17:13:00 EDT
Contents:
Re: What is required of "salt"? ([EMAIL PROTECTED])
Re: Cryptography and Content Protection (Bill Unruh)
Re: What is required of "salt"? (Bill Unruh)
New algorithm for the cipher contest ([EMAIL PROTECTED])
Re: OTP using BBS generator? (Bryan Olson)
Re: 215 Hz five-qubit quantum processor (Maynard Handley)
Re: What is required of "salt"? (John Myre)
Re: CRC? ("Alexander Russell")
Re: What is required of "salt"? (John Myre)
Re: OTP using BBS generator? (Mok-Kong Shen)
Re: Hey geniuses, what's it say? (Scott Craver)
Provable (or probable) primes ("Ed Suominen")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What is required of "salt"?
Date: Mon, 21 Aug 2000 18:53:20 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> 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?
>
> Usually I see the assumption that the salt is "random". I
> don't see, however, why this is so. For example, what would
> be wrong with using a simple counter to generate salt values?
> Or, what if the salt were the concatenation of the user name
> and the server name (or address)? Is there a reason to
> change the salt when we change the password?
Salts only need to be unique. If you can afford that it's ok.
Otherwise just pick a salt at random.
The purpose as you may already know of a salt is to hinder hash-
matching attacks on password system because passwords as simple
as "aaa" can hash to many different valid outputs. The larger the salt
the better.
It also means that people who use the same password will not have the
same passwd hash unless the salt was the same too.
Consider a system with no salts used, all users that pick the
password "aaa" will have the same hash, not only that but all users on
another system will have the same hash. Now if you used a 12 bit salt
for example you have to test "aaa" 4096 times (different hashes).
So make the salts random that's all.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Cryptography and Content Protection
Date: 21 Aug 2000 19:10:42 GMT
In <8nro7g$qqh$[EMAIL PROTECTED]> Adriano Prado <[EMAIL PROTECTED]> writes:
>There are some (printer) extra commands (like some reports) that are
>only available if the user pay for it. That is, the commands are
>already implemented in the firmware, but to use it, I'd like to send a
>key to the printer. The printer should compute the key, based on its
>serial number, to see if it matches.
>The attacker is one who would like to use these commands without paying
>for the key.
>I was thinking in use the same process Unix uses to encrypt its
>passwords. The problem is that the serial number has only five or six
>numbers and with this method one who know a little about crypt would
>crack it too easily...
>I was thinking in use a simple method, like Caesar crypt, adding a
>number to each char (e.g., adding 1: test -> uftu). Of sure there would
>be improvements on this, but one who hack the firmware would find how
>to compute it...
>So... do you have any guess in what should I do?
1) Make an announcement that you have come out with an upgraded version
of your printer ( which you sell for an extra $5) which has these
commands freely available to the user. This whole business of selling
"broken" software and charging for the user to have it "fixed" I think
is silly anyway. Or if you really want, make the user change the ROM
chip to enable the new features.
Remember that you have to encode that extra code, and have to have a
special program for each and every printer you sell-- can't just mass
produce the ROM-- since each ROM must have that special serial number on
board, and you have to keep track of each printer's special number. That
all costs you money whether the customer buys the extra or not.
2) Since you want to use the actual serial number, anyone who knows the
algorithm can figure it out what the correct password is. If it is a
secret serial number-- ie implanted only on the ROM, and not printed on
the back of the printer, the above costs come into consideration.
3) Install some secure authentication scheme, like SRP, or even crypt(3)
or an MD5 hash to encode some special password linked but not the same
as the serial number.
I would go for 1
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: What is required of "salt"?
Date: 21 Aug 2000 19:21:57 GMT
In <[EMAIL PROTECTED]> John Myre <[EMAIL PROTECTED]> writes:
]I'm wondering what (cryptographic) properties "salt" has to have.
None. Its only purpose is to make the same password (eg used by
different users) store differently in the public password file. This way
the attacker will not know when two users have the same password just by
looking at the hashed version. Probably a better scheme would have been
to use the username ( as they are almost guarenteed to be unique) rather
than a one of 4096 random numbers. However, the crypt authors were after
shortness, and since machines could typically have more than 4096 users,
they figured choosing them randomly was a good procedure. For the MD5
hash you could just as well use the user's name (except for the problem
that this would show that the same user on different systems uses the
same passwords on those different system.)
So, the requirements are : a) unique to each user. b) Unique to each
system. c) short. Of course all three cannot be done. Unix crypt opted
for short, (2 alphnumeric encoded characters) and thus figured random
number was best.
You could equally use
username+machineIP, or username+randomnumber to satisfy 1 and 2 without
however having 3
]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?
]Usually I see the assumption that the salt is "random". I
]don't see, however, why this is so. For example, what would
]be wrong with using a simple counter to generate salt values?
]Or, what if the salt were the concatenation of the user name
]and the server name (or address)? Is there a reason to
]change the salt when we change the password?
The only problem with using the system name is that when you change the
system name or ip address, suddenly your whole password base is useless,
and even root cannot log on.
------------------------------
From: [EMAIL PROTECTED]
Subject: New algorithm for the cipher contest
Date: Mon, 21 Aug 2000 19:34:04 GMT
Hi,
I'm submitting a new algorithm to the cipher contest.
The algorithm main characteristics are:
- Doesn't have a Feistel structure.
- The block encryption function presents only four C commands (four
rounds).
- Each round uses 3 primitives operators: one multiplication, one
XOR and one bit-reversal function.
- My old Pentium 166 MHz encrypts 3.06 MBytes/s (54 Cycles/Byte) in
CBC mode. Since the bottleneck is 64-bit multiplications and bit-
reversal, I think a 64-bit processor and some assembly can give
competitive performance.
A simple algorithm like this may be easy to analyze, but I couldn't
break it yet.
I hope the points above might encourage you to take a look at this
cipher.
Please download the documentation and source file (19 KB):
http://www.meubrfree.com.br/~gauss-inf/nimbus/unimbus.cpp
Sorry for my english, my primary language is portuguese.
Thanks
Alexis Machado
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 21 Aug 2000 19:40:25 GMT
Mok-Kong Shen wrote:
>
> Bryan Olson wrote:
> >
> > Mok-Kong Shen wrote:
> > >
> > > Bryan Olson wrote:
> > > >
> > > > Mok-Kong Shen wrote:
> > > >
> > > > > To put the assumptions explicit:
> > > > [...]
> > > > > (3) The apriori
> > > > > probability of the opponent guessing the message is zero.
> > > >
> > > > How could that ever hold?
> > >
> > > You are right in questioning that. A contrived 'theoretical'
> > > case is that the spy cast a perfect die to determine (out
> > > of the blue) what he wants to talk to his colleagues.
> >
> > So in that case the guessing chance is
> >
> > 1 / (number of sides on die).
> >
> > The question is how could it be zero. The only was I see it
> > happening is if the attacker has such bad disinformation
> > about our message space that he assigns zero probability to
> > ever message that is in fact possible.
> >
>
> First of all the 'zero' is understood in the sense of
> probability theory not in the sense of number theory.
> At the time the spy makes up a list for casting a die,
> he has free choice out of a practically unlimited topics
> to be mapped to the die. The die may also be cast a
> multiple times (thus having a larger event space) to
> render the probability you mentioned arbitrarily small.
> Once the topic is selected, he has yet a free choice
> of messages (content). So before the timepoint where
> his huge neuronal network starts to compose the message,
> even the spy himself doesn't know what that message is.
> So I think that justifies to ascribe a probability 0.
That justifies "small" or even "negligible".
Zero is wrong.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Maynard Handley)
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: Mon, 21 Aug 2000 12:50:04 -0700
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>Maynard Handley wrote:
>> I would contend that what's interesting about Godel is more that certain
>> things ARE true, but can't be PROVED true. The standard example is always,
>> of course, Goldbach's conjecture ...
>
>Actually I don't think that is a good example, because our intuition
>is that its proof should be feasible (if it's indeed true). The
>kind of "unprovable truths" we are sure are Godelian are ones that
>are carefully engineered to be self-referential in a suitable coding,
>but they aren't very interesting compared to statements like
>Goldbach's conjecture. Using Godel incompleteness as a possible
>reason why we haven't yet proved some possible theorem seems to be
>a cop-out (a lame excuse).
I think it's a great example because it gets to the root of why this is
interesting. I mean, let's face it, who apart from five logicians in the
world gives a damn about the sort of self-referential statements that
Godel used to prove the theorem? What people actually care about are
things like Golbach or Riemann zeta function zeroes. We assume that if
these things are true, we should be able to prove them---Godel tells us
that is not necessarily the case. Now these may NOT be undecidable---heck,
one could have included Fermat's theorem in the list a few years ago---but
what is interesting is that this option of undecidability is a REAL
possibility.
To put it another way, IMHO this stuff is a whole lot more interesting
when looked at from the point of view of Chaitin, and something like
Goldbach's conjecture naturally falls into Chaitin's view point.
Maynard
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: What is required of "salt"?
Date: Mon, 21 Aug 2000 13:58:37 -0600
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> John Myre <[EMAIL PROTECTED]> wrote:
> >
> > I'm wondering what (cryptographic) properties "salt" has to have.
> >
<snip>
>
> Salts only need to be unique. If you can afford that it's ok.
> Otherwise just pick a salt at random.
<snip>
>
> It also means that people who use the same password will not have the
> same passwd hash unless the salt was the same too.
<snip>
I think you are agreeing with me on the actual requirements of
a salt: (mostly) different for each login, to hide collisions
in passwords.
> So make the salts random that's all.
That's one way. What I'm trying to figure out is if that has
to be the only way. Different situations would make other
alternatives attractive. For instance, if the username could
be taken as the salt, then we don't have to store a salt, we
don't have to "generate" it, we don't have to communicate it.
So - is there a reason why that technique is insecure?
JM
------------------------------
From: "Alexander Russell" <[EMAIL PROTECTED]>
Crossposted-To: alt.msdos.programmer,comp.lang.c,comp.lang.c++,comp.os.msdos.programmer
Subject: Re: CRC?
Date: Mon, 21 Aug 2000 13:14:47 -0700
CRC's are not very good for error correction, but they are very good for
error detection. They are poor for error correction becuase they do not
provide any information on the error, just that there was an error.
code below
Mario Tonni <[EMAIL PROTECTED]> wrote in message
news:8npvk4$m4l$[EMAIL PROTECTED]...
>
>
> Hi there.
> Often I hear the term "CRC", which I know that means
> "cyclic redundancy check".
>
> Thanks!
> Mario
/* crctab calculated by Mark G. Mendel, Network Systems Corporation */
unsigned short crctab[256] = {
0x0000u, 0x1021u, 0x2042u, 0x3063u, 0x4084u, 0x50a5u, 0x60c6u,
0x70e7u,
0x8108u, 0x9129u, 0xa14au, 0xb16bu, 0xc18cu, 0xd1adu, 0xe1ceu,
0xf1efu,
0x1231u, 0x0210u, 0x3273u, 0x2252u, 0x52b5u, 0x4294u, 0x72f7u,
0x62d6u,
0x9339u, 0x8318u, 0xb37bu, 0xa35au, 0xd3bdu, 0xc39cu, 0xf3ffu,
0xe3deu,
0x2462u, 0x3443u, 0x0420u, 0x1401u, 0x64e6u, 0x74c7u, 0x44a4u,
0x5485u,
0xa56au, 0xb54bu, 0x8528u, 0x9509u, 0xe5eeu, 0xf5cfu, 0xc5acu,
0xd58du,
0x3653u, 0x2672u, 0x1611u, 0x0630u, 0x76d7u, 0x66f6u, 0x5695u,
0x46b4u,
0xb75bu, 0xa77au, 0x9719u, 0x8738u, 0xf7dfu, 0xe7feu, 0xd79du,
0xc7bcu,
0x48c4u, 0x58e5u, 0x6886u, 0x78a7u, 0x0840u, 0x1861u, 0x2802u,
0x3823u,
0xc9ccu, 0xd9edu, 0xe98eu, 0xf9afu, 0x8948u, 0x9969u, 0xa90au,
0xb92bu,
0x5af5u, 0x4ad4u, 0x7ab7u, 0x6a96u, 0x1a71u, 0x0a50u, 0x3a33u,
0x2a12u,
0xdbfdu, 0xcbdcu, 0xfbbfu, 0xeb9eu, 0x9b79u, 0x8b58u, 0xbb3bu,
0xab1au,
0x6ca6u, 0x7c87u, 0x4ce4u, 0x5cc5u, 0x2c22u, 0x3c03u, 0x0c60u,
0x1c41u,
0xedaeu, 0xfd8fu, 0xcdecu, 0xddcdu, 0xad2au, 0xbd0bu, 0x8d68u,
0x9d49u,
0x7e97u, 0x6eb6u, 0x5ed5u, 0x4ef4u, 0x3e13u, 0x2e32u, 0x1e51u,
0x0e70u,
0xff9fu, 0xefbeu, 0xdfddu, 0xcffcu, 0xbf1bu, 0xaf3au, 0x9f59u,
0x8f78u,
0x9188u, 0x81a9u, 0xb1cau, 0xa1ebu, 0xd10cu, 0xc12du, 0xf14eu,
0xe16fu,
0x1080u, 0x00a1u, 0x30c2u, 0x20e3u, 0x5004u, 0x4025u, 0x7046u,
0x6067u,
0x83b9u, 0x9398u, 0xa3fbu, 0xb3dau, 0xc33du, 0xd31cu, 0xe37fu,
0xf35eu,
0x02b1u, 0x1290u, 0x22f3u, 0x32d2u, 0x4235u, 0x5214u, 0x6277u,
0x7256u,
0xb5eau, 0xa5cbu, 0x95a8u, 0x8589u, 0xf56eu, 0xe54fu, 0xd52cu,
0xc50du,
0x34e2u, 0x24c3u, 0x14a0u, 0x0481u, 0x7466u, 0x6447u, 0x5424u,
0x4405u,
0xa7dbu, 0xb7fau, 0x8799u, 0x97b8u, 0xe75fu, 0xf77eu, 0xc71du,
0xd73cu,
0x26d3u, 0x36f2u, 0x0691u, 0x16b0u, 0x6657u, 0x7676u, 0x4615u,
0x5634u,
0xd94cu, 0xc96du, 0xf90eu, 0xe92fu, 0x99c8u, 0x89e9u, 0xb98au,
0xa9abu,
0x5844u, 0x4865u, 0x7806u, 0x6827u, 0x18c0u, 0x08e1u, 0x3882u,
0x28a3u,
0xcb7du, 0xdb5cu, 0xeb3fu, 0xfb1eu, 0x8bf9u, 0x9bd8u, 0xabbbu,
0xbb9au,
0x4a75u, 0x5a54u, 0x6a37u, 0x7a16u, 0x0af1u, 0x1ad0u, 0x2ab3u,
0x3a92u,
0xfd2eu, 0xed0fu, 0xdd6cu, 0xcd4du, 0xbdaau, 0xad8bu, 0x9de8u,
0x8dc9u,
0x7c26u, 0x6c07u, 0x5c64u, 0x4c45u, 0x3ca2u, 0x2c83u, 0x1ce0u,
0x0cc1u,
0xef1fu, 0xff3eu, 0xcf5du, 0xdf7cu, 0xaf9bu, 0xbfbau, 0x8fd9u,
0x9ff8u,
0x6e17u, 0x7e36u, 0x4e55u, 0x5e74u, 0x2e93u, 0x3eb2u, 0x0ed1u,
0x1ef0u
};
unsigned long cr3tab[] = { /* CRC polynomial 0xedb88320 */
0x00000000ul, 0x77073096ul, 0xee0e612cul, 0x990951baul, 0x076dc419ul,
0x706af48ful, 0xe963a535ul, 0x9e6495a3ul,
0x0edb8832ul, 0x79dcb8a4ul, 0xe0d5e91eul, 0x97d2d988ul, 0x09b64c2bul,
0x7eb17cbdul, 0xe7b82d07ul, 0x90bf1d91ul,
0x1db71064ul, 0x6ab020f2ul, 0xf3b97148ul, 0x84be41deul, 0x1adad47dul,
0x6ddde4ebul, 0xf4d4b551ul, 0x83d385c7ul,
0x136c9856ul, 0x646ba8c0ul, 0xfd62f97aul, 0x8a65c9ecul, 0x14015c4ful,
0x63066cd9ul, 0xfa0f3d63ul, 0x8d080df5ul,
0x3b6e20c8ul, 0x4c69105eul, 0xd56041e4ul, 0xa2677172ul, 0x3c03e4d1ul,
0x4b04d447ul, 0xd20d85fdul, 0xa50ab56bul,
0x35b5a8faul, 0x42b2986cul, 0xdbbbc9d6ul, 0xacbcf940ul, 0x32d86ce3ul,
0x45df5c75ul, 0xdcd60dcful, 0xabd13d59ul,
0x26d930acul, 0x51de003aul, 0xc8d75180ul, 0xbfd06116ul, 0x21b4f4b5ul,
0x56b3c423ul, 0xcfba9599ul, 0xb8bda50ful,
0x2802b89eul, 0x5f058808ul, 0xc60cd9b2ul, 0xb10be924ul, 0x2f6f7c87ul,
0x58684c11ul, 0xc1611dabul, 0xb6662d3dul,
0x76dc4190ul, 0x01db7106ul, 0x98d220bcul, 0xefd5102aul, 0x71b18589ul,
0x06b6b51ful, 0x9fbfe4a5ul, 0xe8b8d433ul,
0x7807c9a2ul, 0x0f00f934ul, 0x9609a88eul, 0xe10e9818ul, 0x7f6a0dbbul,
0x086d3d2dul, 0x91646c97ul, 0xe6635c01ul,
0x6b6b51f4ul, 0x1c6c6162ul, 0x856530d8ul, 0xf262004eul, 0x6c0695edul,
0x1b01a57bul, 0x8208f4c1ul, 0xf50fc457ul,
0x65b0d9c6ul, 0x12b7e950ul, 0x8bbeb8eaul, 0xfcb9887cul, 0x62dd1ddful,
0x15da2d49ul, 0x8cd37cf3ul, 0xfbd44c65ul,
0x4db26158ul, 0x3ab551ceul, 0xa3bc0074ul, 0xd4bb30e2ul, 0x4adfa541ul,
0x3dd895d7ul, 0xa4d1c46dul, 0xd3d6f4fbul,
0x4369e96aul, 0x346ed9fcul, 0xad678846ul, 0xda60b8d0ul, 0x44042d73ul,
0x33031de5ul, 0xaa0a4c5ful, 0xdd0d7cc9ul,
0x5005713cul, 0x270241aaul, 0xbe0b1010ul, 0xc90c2086ul, 0x5768b525ul,
0x206f85b3ul, 0xb966d409ul, 0xce61e49ful,
0x5edef90eul, 0x29d9c998ul, 0xb0d09822ul, 0xc7d7a8b4ul, 0x59b33d17ul,
0x2eb40d81ul, 0xb7bd5c3bul, 0xc0ba6cadul,
0xedb88320ul, 0x9abfb3b6ul, 0x03b6e20cul, 0x74b1d29aul, 0xead54739ul,
0x9dd277aful, 0x04db2615ul, 0x73dc1683ul,
0xe3630b12ul, 0x94643b84ul, 0x0d6d6a3eul, 0x7a6a5aa8ul, 0xe40ecf0bul,
0x9309ff9dul, 0x0a00ae27ul, 0x7d079eb1ul,
0xf00f9344ul, 0x8708a3d2ul, 0x1e01f268ul, 0x6906c2feul, 0xf762575dul,
0x806567cbul, 0x196c3671ul, 0x6e6b06e7ul,
0xfed41b76ul, 0x89d32be0ul, 0x10da7a5aul, 0x67dd4accul, 0xf9b9df6ful,
0x8ebeeff9ul, 0x17b7be43ul, 0x60b08ed5ul,
0xd6d6a3e8ul, 0xa1d1937eul, 0x38d8c2c4ul, 0x4fdff252ul, 0xd1bb67f1ul,
0xa6bc5767ul, 0x3fb506ddul, 0x48b2364bul,
0xd80d2bdaul, 0xaf0a1b4cul, 0x36034af6ul, 0x41047a60ul, 0xdf60efc3ul,
0xa867df55ul, 0x316e8eeful, 0x4669be79ul,
0xcb61b38cul, 0xbc66831aul, 0x256fd2a0ul, 0x5268e236ul, 0xcc0c7795ul,
0xbb0b4703ul, 0x220216b9ul, 0x5505262ful,
0xc5ba3bbeul, 0xb2bd0b28ul, 0x2bb45a92ul, 0x5cb36a04ul, 0xc2d7ffa7ul,
0xb5d0cf31ul, 0x2cd99e8bul, 0x5bdeae1dul,
0x9b64c2b0ul, 0xec63f226ul, 0x756aa39cul, 0x026d930aul, 0x9c0906a9ul,
0xeb0e363ful, 0x72076785ul, 0x05005713ul,
0x95bf4a82ul, 0xe2b87a14ul, 0x7bb12baeul, 0x0cb61b38ul, 0x92d28e9bul,
0xe5d5be0dul, 0x7cdcefb7ul, 0x0bdbdf21ul,
0x86d3d2d4ul, 0xf1d4e242ul, 0x68ddb3f8ul, 0x1fda836eul, 0x81be16cdul,
0xf6b9265bul, 0x6fb077e1ul, 0x18b74777ul,
0x88085ae6ul, 0xff0f6a70ul, 0x66063bcaul, 0x11010b5cul, 0x8f659efful,
0xf862ae69ul, 0x616bffd3ul, 0x166ccf45ul,
0xa00ae278ul, 0xd70dd2eeul, 0x4e048354ul, 0x3903b3c2ul, 0xa7672661ul,
0xd06016f7ul, 0x4969474dul, 0x3e6e77dbul,
0xaed16a4aul, 0xd9d65adcul, 0x40df0b66ul, 0x37d83bf0ul, 0xa9bcae53ul,
0xdebb9ec5ul, 0x47b2cf7ful, 0x30b5ffe9ul,
0xbdbdf21cul, 0xcabac28aul, 0x53b39330ul, 0x24b4a3a6ul, 0xbad03605ul,
0xcdd70693ul, 0x54de5729ul, 0x23d967bful,
0xb3667a2eul, 0xc4614ab8ul, 0x5d681b02ul, 0x2a6f2b94ul, 0xb40bbe37ul,
0xc30c8ea1ul, 0x5a05df1bul, 0x2d02ef8dul
};
/*
* updcrc macro derived from article Copyright (C) 1986 Stephen Satchell.
* NOTE: First argument must be in range 0 to 255.
* Second argument is referenced twice.
*
* Programmers may incorporate any or all code into their programs,
* giving proper credit within the source. Publication of the
* source routines is permitted so long as proper credit is given
* to Stephen Satchell, Satchell Evaluations and Chuck Forsberg,
* Omen Technology.
*/
extern unsigned short crctab[256];
#define updcrc(cp, crc) ( crctab[((crc >> 8) & 255)] ^ (crc << 8) ^ cp)
extern unsigned long cr3tab[]; /* CRC polynomial 0xedb88320 */
#define UPDC32(b, c) (cr3tab[((int)c^b) & 0xffu]^((c >> 8) & 0x00FFFFFFul))
/* -------------------- calc_crc16() ------------------- January 10,1996 */
unsigned short calc_crc16(char *s, unsigned int len)
{
unsigned short crc=0;
while ( len )
{
crc=updcrc((0377 & *s), crc);
s++;
len--;
}
return crc;
}
/* --------------------- calc_crc32() ------------------- January 10,1996 */
unsigned long calc_crc32(char *s, unsigned int len)
{
unsigned long crc=0;
while ( len )
{
crc=UPDC32((0377 & *s), crc);
s++;
len--;
}
return crc;
}
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: What is required of "salt"?
Date: Mon, 21 Aug 2000 14:37:50 -0600
Bill Unruh wrote:
>
> In <[EMAIL PROTECTED]> John Myre <[EMAIL PROTECTED]> writes:
>
> ]I'm wondering what (cryptographic) properties "salt" has to have.
>
> None.
Ah, then I'll just use zero. :)
> Its only purpose is to make the same password (eg used by
> different users) store differently in the public password file.
That's the only requirement I've ever seen, as well.
> Probably a better scheme would have been
> to use the username ( as they are almost guarenteed to be unique) rather
> than a one of 4096 random numbers. However, the crypt authors were after
> shortness, and since machines could typically have more than 4096 users,
> they figured choosing them randomly was a good procedure.
Shortness where? If you could take the username as the salt, then
salting would cost zero in storage, since the username has to be
there anyway. As far as historical design choices go, I'd bet that
the variable length of the username was their (perceived) problem.
> For the MD5
> hash you could just as well use the user's name (except for the problem
> that this would show that the same user on different systems uses the
> same passwords on those different system.)
In the Unix systems I've seen, the problem is usually there anyway.
The password file (with salts) is often copied to the next system,
rather than creating new logins. Ok, so that's not good - but I'm
not sure salt is where to stop that. That is, if you actually do
use the same password on multiple systems, then you are as vulnerable
as the least secure system, even without the attacker knowing it.
In a practical sense, it can be *better* to use the same password
everywhere, because you can pick a good one (and remember it).
Or it can be worse, because now you think passwords aren't important.
It does seem intuitively obvious that we want the attacker to know
as little as possible. It would presumably be better not to reveal
whether or not passwords were the same on different systems for the
same person. However, I'm not really convinced of this, because
I'm not sure what *advantage* the attacker gains.
> So, the requirements are : a) unique to each user.
Ok.
> b) Unique to each system.
Arguably.
> c) short.
Why? That is, does that requirement have any cryptographic
purpose, or are you referring to practical constraints?
<snip>
> The only problem with using the system name is that when you change the
> system name or ip address, suddenly your whole password base is useless,
> and even root cannot log on.
Hm. Good point. I've seen systems in which breaking logins when
you change the ip address would be a good thing, but not usually.
"Hardly ever," in fact.
In a practical system, we could probably finesse this somehow; if
it were given that using systemname:username for salt is a good
idea otherwise.
I can certainly imagine systems in which salts are other than
random numbers are handy. Different systems, different techniques.
At this point I'm still seeing if anybody can come up with any
*cryptographic* requirements, other than uniqueness.
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 21 Aug 2000 22:57:58 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> >
> > Bryan Olson wrote:
> > >
> > > Mok-Kong Shen wrote:
> > > >
> > > > Bryan Olson wrote:
> > > > >
> > > > > Mok-Kong Shen wrote:
> > > > >
> > > > > > To put the assumptions explicit:
> > > > > [...]
> > > > > > (3) The apriori
> > > > > > probability of the opponent guessing the message is zero.
> > > > >
> > > > > How could that ever hold?
> > > >
> > > > You are right in questioning that. A contrived 'theoretical'
> > > > case is that the spy cast a perfect die to determine (out
> > > > of the blue) what he wants to talk to his colleagues.
> > >
> > > So in that case the guessing chance is
> > >
> > > 1 / (number of sides on die).
> > >
> > > The question is how could it be zero. The only was I see it
> > > happening is if the attacker has such bad disinformation
> > > about our message space that he assigns zero probability to
> > > ever message that is in fact possible.
> > >
> >
> > First of all the 'zero' is understood in the sense of
> > probability theory not in the sense of number theory.
> > At the time the spy makes up a list for casting a die,
> > he has free choice out of a practically unlimited topics
> > to be mapped to the die. The die may also be cast a
> > multiple times (thus having a larger event space) to
> > render the probability you mentioned arbitrarily small.
> > Once the topic is selected, he has yet a free choice
> > of messages (content). So before the timepoint where
> > his huge neuronal network starts to compose the message,
> > even the spy himself doesn't know what that message is.
> > So I think that justifies to ascribe a probability 0.
>
> That justifies "small" or even "negligible".
> Zero is wrong.
Then kindly give me an example of yours that can
serve to illustrate a probability of measure zero
so that we could have a compararison.
BTW, I did forget an additional assumption that is
essential: (6) The encryption is performed in a
tempest-proof enviroment. Otherwise, the opponent
has an easy job.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: alt.paranormal.crop-circles,sci.skeptic
Subject: Re: Hey geniuses, what's it say?
Date: 21 Aug 2000 20:47:07 GMT
In article <8nq5mk$a0u$[EMAIL PROTECTED]>, <.> wrote:
>Someone you all love to hate came up with this code, many moons ago.
>Has something to say.
>
>134596487 252431012 944695718 83842686593 8592167
>47339615370887497 37284822939766173 553245255734286
>769482821!!!
>
>3284377 83287697534, 914418892586392 787861494296534,
>836278374309673 778331662 4326381 72748174935
>76692689069918366 50491207599657797118280!
>
>83861222610135, 91369648073923, 14940135 1671948239
>2901858965034959..............
How weird. In the first two paragraphs all the "words"
contain an odd number of symbols, in the third paragraph
every word, an even number.
Assuming this isn't a random garble made up by the
poster to annoy people, what cipher would produce such
an extremely odd, then even output? I also notice
that the smallest words have 7 digits; not impossible
but maybe indicative of a cipher with an awful expansion
factor.
>It's not very nice what he says, but you all deserve it!
-S
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Subject: Provable (or probable) primes
Date: Mon, 21 Aug 2000 14:00:05 -0700
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Below are a bunch of odd integers just below 2^32.
Can anyone run them through some suitable software and let me know
which ones (if any) are prime? (Integers ending with 5 are omitted
for obvious reasons.) Also, please indicate the primality test you
used. (Who knows, maybe they're short enough to try factoring on a
desktop.)
- --
Ed Suominen
Registered Patent Agent, Crypto Hobbyist
- - 90% ignorant two months ago
- - 75% ignorant last month
- - Now shooting for 50% ignorant...
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
2^32 = 4294967296
- -------------------------
4294967293
4294967291
4294967289
4294967287
4294967283
4294967281
4294967279
4294967277
4294967273
4294967271
4294967269
4294967267
4294967263
4294967261
4294967259
4294967257
4294967253
4294967251
4294967249
4294967247
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.3
iQA/AwUBOaGYU6mKuMvNCWDGEQLH3ACdGwsUT0Sv7FLDka/0L987g5zLp2UAoKlz
PjAPVmfp5u3RcN1Ob0iwKqkP
=1B7m
=====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
******************************
