Cryptography-Digest Digest #605, Volume #13 Thu, 1 Feb 01 17:13:00 EST
Contents:
Re: ideas of D.Chaum about digital cash and whether tax offices are (Darren New)
Re: Diffie Helman (DJohn37050)
Re: Breaking OAP-L3 (Anthony Stephen Szopa)
Re: How good is Diamond2 and Saphire ciphers? (Rex Stewart)
Re: Most secure code for US Citizen. (Michael Robbins)
Re: fast signing (David Hopwood)
Re: MIKE - alternative to SPEKE and PAK (David Hopwood)
Re: Very short redundant serial number (Paul Rubin)
Re: Breaking OAP-L3 (John Savard)
Re: fast signing (DJohn37050)
Re: Very short redundant serial number ([EMAIL PROTECTED])
Re: New checksum algorithm (Sami J. M�kinen)
Re: Very short redundant serial number (Paul Rubin)
Re: New checksum algorithm ("Stefan Habenschuss")
Re: New checksum algorithm ("Stefan Habenschuss")
Re: How good is Diamond2 and Saphire ciphers? ("Paul Pires")
Re: What do you do with broken crypto hardware? (Steve Roberts)
coincidence ("caffino")
Re: Very short redundant serial number ([EMAIL PROTECTED])
Re: Recommendations on simplest way to add client/server encryption (Angry Bob)
----------------------------------------------------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are
Date: Thu, 01 Feb 2001 18:40:14 GMT
Thomas J. Boschloo wrote:
> Another problem with anonymous cash is that combined with anonymous
> publishing, it will not be possible to stop commercial child porn.
Of course it will. You arrest the people taking the photographs. You arrest
the people kidnapping (or whatever) the children. This is like saying that
without phone taps, you can't catch contract killers.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Ignorance can be cured. Naivety cures itself.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 01 Feb 2001 18:40:58 GMT
Subject: Re: Diffie Helman
Bob S. had a (obvious) typo. Alice knows x but does not know y and vice versa
for Bob.
Don Johnson
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: Breaking OAP-L3
Date: Thu, 01 Feb 2001 10:59:24 -0800
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > Breaking OAP-L3
> >
> > (I just let my old web account expire and am now using pacbell news
> > server. Oh, boy.
> >
> > Seems like some of the news group posts are not here. And I cannot
> > get some news groups.
> >
> > But here is to the poster whose post isn't here on pacbell's news
> > server but that I saw on my old ISP's news server.)
> >
> > Breaking OAP-L3? What is there to talk about?
>
> Not much since you have yet to provide any cryptanalysis yourself. Just
> because you can think of a complete break there might be slight weaknesses.
>
> And BTW no one is going to download your .exe and run them. Provide clear
> concise papers describing your algorithms and we shall have a go at it.
>
> Why can't you do things like the group has been asking (for a year!).
>
> Tom
>
> Sent via Deja.com
> http://www.deja.com/
I have. There are a total of three pages. That's all.
They are the Theory and Processes I & II web pages in the Help
Files at http://www.ciphile.com.
I realize this is all too difficult locate and read.
I understand.
Thanks for helping me confirm that pacbell news server functions.
AS
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: How good is Diamond2 and Saphire ciphers?
Date: Thu, 01 Feb 2001 19:01:52 GMT
Assuming you are talking about ciphers Micheal P. Johnson
developed in the early 90's:
Diamond2 is a classical substitution-permutation cypher
which although very strong, is not very fast. The cypher
was designed with strength in mind, but not much concern
for speed. In fact one of the positive aspects of this
cypher is the slowness of key setup - which takes several
million processor cycles. This increases the cost of
brute forcing the key (known as key strengthening).
Sapphire2 (do not confuse with the original version, which
was shown to have a weakness) is a stream cypher which is
designed to be both fast, and moderately strong.
I am not a professional cryptographer by any stretch of the
imagination, but I did a pretty thourough examination of this
cypher before I decided to use it.
It has some similarities to RC4 but with an extra twist that
it feeds information from both the plaintext and the cyphertext
streams into the system. This allows it to be used repeatedly
with a single key, unlike standard stream cyphers.
While feeding back information from either plaintext OR
cyphertext streams is considered a dangerous practice - he
used both, which complicates attacks somewhat, and I don't
think anyone has come up with any useful attacks.
As for whether these cyphers are good for the future - it
depends on what you intend to use them for. No one (as
far as I know) is creating applications using these cyphers.
(The only aplications I know for Sapphire2 are ATBASH
and --- hmmm, drawing a blank right now, but I know there
were two others) OTOH - in the (eight or nine?) years since
they were presented to the cryptographic community, no one
has found any useful attacks based on either the cyphers
or the componets used to biuld them.
In article <95a5or$2ugu$[EMAIL PROTECTED]>,
"ddd" <[EMAIL PROTECTED]> wrote:
> How good is Diamond2 and Saphire ciphers?
> Are these ciphers good for future?
>
>
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Michael Robbins <[EMAIL PROTECTED]>
Subject: Re: Most secure code for US Citizen.
Date: Thu, 01 Feb 2001 19:13:32 GMT
Thank you for your answers. Like most users, I had not thought about
the subtleness of the issues. I was hoping for an easy solution.
Basically I write computer models as part of my work. I cannot compile
them completely and I must carry and use source code. What I can
compile can be decrypted by at least one third party without my control
since I did not write the virtual machine code algorithm.
Should a competitor obtain some or all of my code, he will likely have
vast resources at his disposal (including a "supercomputer" and several
Math Phds.), if not an actual knowledge of cryptography.
I'd like to provide as much protection against reverse engineering as I
can while limiting the impact on my productivity.
Naively, I assumed that encrypting the source and data would help but I
now realize that a skilled person may be able to retrieve valuable clues
in other ways, be it through traces left on my drive or records left in
my OS.
I'm not quite sure the protection is worth the effort. It certainly
seems like a great deal of work.
--
Michael Robbins, CFA
Director, Debt Capital Markets
Canadian Imperial Bank of Commerce, World Markets
New York
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Thu, 01 Feb 2001 19:22:30 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: fast signing
=====BEGIN PGP SIGNED MESSAGE=====
DJohn37050 wrote:
> Thanks for pointing this out, I thought it was clear from context, but
> obviously not.
>
> When compared to the modulus, the public exponent must have 160 bits of
> high order zeros, according to X9.31.
How very odd. I can see that this would preclude small d, but I don't
see why that would lead to any security advantage, given that there are
lots of other ways to have an insecure d. Doesn't it just introduce a
gratuitous incompatibility with other RSA standards?
- --
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
iQEVAwUBOnj4MzkCAxeYt5gVAQHx1ggAoClGJxccQXSo/bZtN3qeXqj4Mvl3UPNq
2L5nKY5f6MCHrC/YGOR3IhLLVYgAXoduUjTRMbhTnBP4EHC67KlNO5fT6Xx46wLw
vbKDgrEyo5c2RKVC2swG0zAsk5jZjafXKhO6PjqUEJHyn8nf4VOgPnK+PFcyFwV3
agdIP4QZIrmqUrAeRYJ5elkwHlL7zTg5Q/b7bny5mo4yesNQkO9UAl0wAlFpJu8e
VkXj8IT5U5gCxeERPJ8Sd+gge+5yptFNSy8G5aa4wBSWryAIkrnOfVPt6O7l1y6I
srDmX/nikkBk6E7LLoKgKhvWLq16Ch2mYOkcBV6j4uJoTWKaJWE7IQ==
=ezbM
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 01 Feb 2001 19:22:39 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: MIKE - alternative to SPEKE and PAK
=====BEGIN PGP SIGNED MESSAGE=====
Michael Scott wrote:
> OK, so this might be better (must get that paper). Variables a,b and r
> are randomly selected
>
> 3. Carol: A=3^a mod p, Carol sends A to Steve
> 4. Steve: B=3^b.v^r. u=4^r. Steve sends B and u to Carol.
> 5. Carol calculates S=(B/u^x)^a. Steve calculates S=A^b
>
> Then proceed as for SRP. Note that 3 and 4 are both generators of the
> (p-1)/2 sub-group for any safe prime.
I.e. written out in full,
Let p be a large safe prime,
P be Carol's password,
s be a random salt,
x = H(s, P) be Carol's password-derived secret,
v = 4^x mod p be the verifier for Carol,
Carol -> Steve: username
Steve -> Carol: s
Carol: x = H(s_C, P)
choose a uniformly at random in [0, (p-1)/2 - 1]
Carol -> Steve: A = 3^a mod p
Steve: abort if A_S = 0 (mod p)
choose b and r uniformly at random in [0, (p-1)/2 - 1]
Steve -> Carol: B = 3^b.v^r mod p, u = 4^r mod p
Carol: abort if B_C or u_C = 0 (mod p)
S_C = (B_C.u_C^-x)^a
K_C = H(S_C)
Steve: S_S = A_S^b
K_S = H(S_S)
[S_C should equal S_S because (3^b.v^r.4^-rx)^a = 3^ab]
Carol -> Steve: M1 = H(username, s_C, A_C, B_C, K_C)
Steve: abort if M1_S != H(username_S, s_S, A_S, B_S, K_S)
Steve -> Carol: M2 = H(A_S, M1_S, K_S)
Carol: abort if M2_C != H(A_C, M1_C, K_C)
[Steve and Carol's view of certain variables are shown using subscripts
_S and _C respectively. So for example "Carol -> Steve: A = 3^a mod p"
is shorthand for Carol calculating A_C = 3^a mod p, and Steve receiving
A_S. I find this sometimes helps analysis, since in a MITM attack, what
is sent is not necessarily what is received.
The abort conditions and the final steps to prove that Carol and Steve
have the same K are taken from the SRP specs.]
Here is a client impersonation attack on this protocol:
Carrie -> Steve: Carol's username
Steve -> Carrie: s
Carrie -> Steve: A = 1
Steve: does not abort, since A != 0 (mod p)
choose b and r uniformly at random in [0, (p-1)/2 - 1]
Steve -> Carrie: B = 3^b.v^r mod p, u = 4^r mod p
Carrie: K_C = H(1)
Steve: S_S = A_S^b = 1
K_S = H(1)
Carrie -> Steve: M1 = H(Carol's username, s, 1, B, H(1))
Steve: does not abort, i.e. Carrie successfully
impersonates Carol.
OK, so the checks should be that A, B, u != {0, 1, p-1} (mod p), to
avoid small subgroups for each of these variables.
A similar type of attack is to try to force one or more of the group
elements into a different subgroup than expected. For example, a MITM
attacker could multiply the value of u by -1 (mod p) in Steve's message
to Carol. If x is odd, this change causes the protocol to fail; if x is
even then it does not (because -1^x = 1 (mod p)). So this leaks one bit
of information about x. I think other small subgroup attacks are prevented
by the use of a safe prime, but in any case, this suggests that u should
be included in the values hashed to give M1 (so that changing u would
always cause the protocol to fail).
I'd almost concluded that the protocol was secure with these changes,
but here is an off-line dictionary attack, by an attacker Stevie who
impersonates the server:
Carol -> Stevie: username
Stevie -> Carol: s
Carol: x = H(s, P)
choose a uniformly at random in [0, (p-1)/2 - 1]
Carol -> Stevie: A = 3^a mod p
Stevie -> Carol: B = 3, u = 3
Carol: does not abort, since B_C, u_C != {0, 1, p-1} (mod p)
S_C = (3.3^-x)^a
K_C = H(S_C)
Carol -> Stevie: M1 = H(username, s_C, A_C, B_C, K_C, u_C)
Stevie: drop connection
for (each password P' from a dictionary) {
[note that S_C = (3.3^-x)^a = 3^a.3^-ax = A^(1-x)]
S' = A^(1 - H(s, P'))
M1' = H(username, s, A, 3, H(S'), 3)
if M1' = M1, P' is almost certainly the correct password
}
Nice try, though. Maybe this could be fixed by doing the Elgamal
encryption and the key exchange in completely separate subgroups [*]
(e.g. p-1 = 2qrs for q, r, and s distinct large primes, and use the
q and r-order subgroups), since then Carol could check that B and u
were each in the correct subgroup. That foils the immediate attack,
since if B is in a subgroup generated by g, and u in a subgroup
generated by g', then Stevie would have to be able to calculate
g'^a from g^a, and I think that is hard (but I'm not entirely sure).
[*] by separate, I mean distinct apart from the element 1.
Don't be disheartened, BTW - the first two iterations of SRP were also
broken on sci.crypt. Designing strong password protocols is difficult.
- --
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
iQEVAwUBOnj0/DkCAxeYt5gVAQEhCwgAkYEc9JTF2ljSdPX2Srwe8+9a2R6bELwM
NDgC5zV6HehoL+4OooQ1JITXXLvje/bZZeW6TSm4CLDlxtxCNSYhrglHWAT0r+Bd
e35of2BMJ4Y+axjRSPjIS4uwo3HwHssaEy5VkOzt8M0rZXYtiMTkWh3PnHFAE5b4
P1WuU7A2dwLCuVLerqBRJOdNcD5zmD3m0g8dH4UA008Gx61R0mvx6u2RMu+QEY5J
78yrHOm85tZaNuupTa13S3oOnDx4TII8jSwqjXjHRXmexAQJYnF7Jb2F1PH+wq9l
CykCq+SMzivcSN/ccJ4V/W630j/D91jpwbRLrrtcImsihc2wu/pj0w==
=qeyt
=====END PGP SIGNATURE=====
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Very short redundant serial number
Date: 01 Feb 2001 11:36:12 -0800
[EMAIL PROTECTED] writes:
> I am considering a bit-swap table, like DES, but I don't feel
> comfortable picking the table out of thin air.
>
> Still seeking ideas.
Don't be so fancy. Just about everyone uses a simple CRC for things
like this.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: Breaking OAP-L3
Date: Thu, 01 Feb 2001 20:06:24 GMT
On Thu, 01 Feb 2001 00:34:41 -0800, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote, in part:
>Breaking OAP-L3
>Breaking OAP-L3? What is there to talk about?
>If you think you can break it then do so.
>Email me if you can accomplish this feat.
>I really don't know of any way for me to get involved in a
>discussion of this matter unless someone can prove that they can
>accomplish the above.
a) There are lots of ciphers that I can't break that are considerably
weaker than the recommended major ciphers like Rijndael. Ciphers are
generally considered unfit for use on much weaker grounds than being
actually cracked, based on studying the algorithm, and finding
_potential_ ways they might be cracked, with more known plaintext than
would be obtained in practice.
b) You refer to 'generating' OTP data, presumably by an algorithmic
process. That is a contradiction in terms.
If there is a description of your algorithm on your web site, fine.
Otherwise, unless someone did really crack OAP-L3, judgements on its
appropriateness and security still have to be made; and they will be
made on things like how you sound in this newsgroup, because the only
other information of relevance is whether or not you appear to be
competent and knowledgeable.
As you may have noted, the world is not falling over itself to take
advantage of OAP-L3. The FAQ for this newsgroup - recently reposted -
may possibly contain some clues as to why.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 01 Feb 2001 20:10:08 GMT
Subject: Re: fast signing
Many use small exponents, 3, 5, 17, 35567 so this presents NO problem there.
X9.31 requires that the public exponent be selected first, so this can be seen
as a way to help ensure that this was done. By choosing the public exponent
first, it is VERY unlikely to have a too small private exponent.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Very short redundant serial number
Date: Thu, 01 Feb 2001 20:13:04 GMT
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> > I am considering a bit-swap table, like DES, but I don't feel
> > comfortable picking the table out of thin air.
> >
> > Still seeking ideas.
>
> Don't be so fancy. Just about everyone uses a simple CRC for things
> like this.
>
Fair enough, but can anyone point me to a very small implementation of
a 2 digit (basically 3 or 4 bit) CRC? I can't afford the table used in
the 32bit version I have handy, and anyway it would be pointless to
generate a 32bit CRC and then mod 100 it.
Ken
Sent via Deja.com
http://www.deja.com/
------------------------------
Subject: Re: New checksum algorithm
From: [EMAIL PROTECTED] (Sami J. M�kinen)
Date: Thu, 01 Feb 2001 20:28:43 GMT
I wrote earlier:
>for ( i = 0; i < n; i++ )
>{
> tmp = buffer[i];
One improvment with one more XOR. tmp = buffer[i] ^ sum;
- Should be much better.
Regards,
Sami J. M�kinen / [EMAIL PROTECTED]
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Very short redundant serial number
Date: 01 Feb 2001 13:14:04 -0800
[EMAIL PROTECTED] writes:
> Fair enough, but can anyone point me to a very small implementation of
> a 2 digit (basically 3 or 4 bit) CRC? I can't afford the table used in
> the 32bit version I have handy, and anyway it would be pointless to
> generate a 32bit CRC and then mod 100 it.
The tables used in big CRC implementations are not needed; they just
let you CRC several (usually 8) bits at a time, in order to make the
checksum go faster. The basic CRC operation is:
for (each bit of input)
CRC <<= 1;
if (input bit is 1)
CRC ^= POLY;
where POLY is the CRC polynomial you're using. The table just lets
you do a bunch of these operations in one step, but you don't need it.
Ross Williams has a very thorough explanation of CRC calculation on a
page somewhere that you can probably find with a web search.
The reference to Numerical Recipes about using the D10 group sounds
interesting and worth checking out. I have that book but don't
remember anything about it.
------------------------------
From: "Stefan Habenschuss" <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Thu, 01 Feb 2001 21:19:15 GMT
> I decided to design my first checksum algorithm (for non-crypto purpose),
> I hope you don't mind posting it here since this should not be far off
> topic.
>
> The goal was to have extremely high speed in 32-bit Pentium platform.
>
> The algorithm is very simple, it works on 32-bit words and requires
> 2 ADDS, 3 SHIFTS and 1 XOR for one 32-bit word. The core is easy to
> represent in C-code:
>
> uint32 *buffer;
> uint32 i, tmp;
>
> sum = 1;
>
> for ( i = 0; i < n; i++ )
> {
> tmp = buffer[i];
> tmp = (uint32) (sum >> 29) + tmp;
> tmp = (uint32) (sum >> 17) + tmp;
> sum = (uint32) (sum << 3) ^ tmp;
> }
>
> return sum;
>
> My C-code implementation is about 33% faster than Adler32 and 5 times
> as fast as CRC32.
>
> I'm not a scientist so I'm asking for someone to comment on it.
>
> Thanks for your time.
>
>
> Regards,
>
> Sami J. M�kinen / [EMAIL PROTECTED]
You said this algorithm was for non-crypto use so I don't know what specific
design goals you had when creating it (apart from "extremely high speed").
Anyway, from the cryptographic point of view, your algorithm fails at least
to meet one of the basic requirements for modification detection codes,
namely collision resistance, which means that it should be difficult to find
two different inputs having the same hash-value.
Suppose you have an input size of six 32-bit values having the hash-value
c6. Now if you want to find a different input of the same size which gives
us that value, you only have to do the following:
- choose 5 random values v1 - v5 and compute the checksum c5 for those 5
values
- for your original algorithm just compute:
v5 = (c6 xor (c5 * 8)) - (c5 div 2^29 + c5 div 2^17)
for your suggested "improvement" just xor the result above with c5
As you can see your algorithm is far too linear to provide really good and
widely usable hash-values. I'm sorry if that wasn't your aim at all, anyway.
If you use your algorithm only for harmless integrity checks on your home
computer, it still might be a quite good algorithm.
------------------------------
From: "Stefan Habenschuss" <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Thu, 01 Feb 2001 21:24:36 GMT
correction of typo:
v6 = (c6 xor (c5 * 8)) - (c5 div 2^29 + c5 div 2^17)
^^
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: How good is Diamond2 and Saphire ciphers?
Date: Thu, 1 Feb 2001 13:27:53 -0800
Rex Stewart <[EMAIL PROTECTED]> wrote in message news:95cbqp$4nu$[EMAIL PROTECTED]...
> Assuming you are talking about ciphers Micheal P. Johnson
> developed in the early 90's:
>
<Snip>
>
> Sapphire2
> It has some similarities to RC4 but with an extra twist that
> it feeds information from both the plaintext and the cyphertext
> streams into the system. This allows it to be used repeatedly
> with a single key, unlike standard stream cyphers.
This sounds like something interesting. Can you give me any pointers
to where I might find a description of this? I'll give Google a go but
a reccomendation would be appreciated.
Thanks,
Paul
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (Steve Roberts)
Subject: Re: What do you do with broken crypto hardware?
Date: Thu, 01 Feb 2001 21:45:32 GMT
I would essentially agree. The parts of the unit that hold or may
have held crypto materials must be physically destroyed with the
proper witnesses present. Floppies go into the shredder and I have
known a bank that sent someone trotting along to SimsMetal to toss
hard disk platters (already physically damaged) into their crusher.
I know of a governmental institution that had similar problems. I
believe their broken stuff was first of all broken some more, then
encased in reinforced concrete and dropped into the ocean halfway
along a voyage of some sort. Destroying magnetic tapes were a real
problem - I suggested a sort of schoolboy bomb that would melt the
matrix into a sort of goo.
Secure hardware in dodgy locations (liable to get captured in war etc)
can have its own chemical/explosive kit installed - for example a
little explosive charge on each VLSI chip - you might not have time to
whop it with a sledgehammer. (And when they come over the wall, the
guy hitting things with the sledgehammer will be the focus of
interest).
Steve
>In my bank IT Security experience (not Citibank), a faulty unit would either
>be compacted along with a junk car body, or industrial incineration,
>witnessed by myself or other relevant bank person.
>
>Lyal
>
>Paul Rubin wrote in message <[EMAIL PROTECTED]>...
>>[EMAIL PROTECTED] (Peter Gutmann) writes:
>>> In addition, erasing the cell doesn't necessarily mean the data is
>>> really gone. If you're really concerned I'd physically destroy the
>>> memory, and if you're really paranoid and worried about big-budget
>>> attackers, the crypto device it fed as well.
>>
>>I'm wondering what normal policy is in high security commercial
>>organizations, e.g. What Would Citibank Do? In practice I don't think
>>we're that paranoid. We're just trying to identify and follow best
>>industry practices for this type of operation.
>
>
------------------------------
From: "caffino" <[EMAIL PROTECTED]>
Subject: coincidence
Date: Thu, 1 Feb 2001 22:57:46 +0100
Hi
Mayby someone know how look mathematical formula for (I`m not sure that it
is the right name for it in english) 'counting coincidence'.
O sites where I could find it.
Caff
sorry for mistakes
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Very short redundant serial number
Date: Thu, 01 Feb 2001 21:51:24 GMT
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> The table just lets
> you do a bunch of these operations in one step, but you don't need it.
> Ross Williams has a very thorough explanation of CRC calculation on a
> page somewhere that you can probably find with a web search.
Thanks, this is helpfull. I will try your reference, and I have
another here by Terry Ritter. My only real remaining theoretical
question is whether I can mod 100 a 16bit CRC without destroying the
CRC properties, when the input data is only two digits. I have the
16bit CCITT poly, but 7 and 8 bit variants are hard to come by. There
is one for you math guys.
> The reference to Numerical Recipes about using the D10 group sounds
> interesting and worth checking out. I have that book but don't
> remember anything about it.
Indeed, it looks interesting, but I don't have the book and could do
without the tables. Besides, a solution in hand is better than two on
the shelf. :-)
Ken
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Angry Bob <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Recommendations on simplest way to add client/server encryption
Date: 1 Feb 2001 21:58:49 GMT
What would you like to read? [comp.security.misc or *?]
This is a Rob Yampolsky <[EMAIL PROTECTED]> scroll! it says:
> In the case of a not-very-widely distributed, closed-source client, just how
> paranoid do I need to be?
very, since they'll probably be able to cause an overflow with a minumum
of tinkering.
--
AngryBob
I am no longer being silly!
-Josh Litherland
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
