Cryptography-Digest Digest #287, Volume #13 Thu, 7 Dec 00 08:13:01 EST
Contents:
Re: hardware RNG's ("Frog2000")
Re: How to embed a key in executable code? ("Matt Timmermans")
Where could I find sources of crypt algorithms? (in some programming language)
("Noname")
Re: weten we die PIN? (David Dylan)
Re: weten we die PIN? ("Jan Hein Mastenbroek")
Re: Idea for ciphering? (Jorgen Hedlund)
Re: Idea for ciphering? (correction w/ addition) (Jorgen Hedlund)
Re: Idea for ciphering? (Jorgen Hedlund)
Re: Smart Card vs 1.44 Disk (Daniel James)
Re: weten we die PIN? (David Dylan)
Re: Idea for ciphering? (Mok-Kong Shen)
Re: Where could I find sources of crypt algorithms? (in some programming (Mok-Kong
Shen)
Re: Hamming Distance (Paul Crowley)
Re: Wei Dai Crypto++ and PGP SDK ("M.S. Bob")
Re: Where could I find sources of crypt algorithms? (in some programming ("M.S.
Bob")
Re: Idea for ciphering? (Jorgen Hedlund)
Re: Math background required for Cryptology ? ("M.S. Bob")
Re: Math background required for Cryptology ? (Dido Sevilla)
Re: How to embed a key in executable code? (Tim Tyler)
Re: Hamming Distance (Tim Tyler)
Re: Where could I find sources of crypt algorithms? (in some programming (Dido
Sevilla)
Re: Fips Pub 140-1 and RNG (Tim Tyler)
Re: Wei Dai Crypto++ and PGP SDK (Tom St Denis)
Re: How to embed a key in executable code? (Tom St Denis)
----------------------------------------------------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Thu, 7 Dec 2000 00:18:33 -0500
Good points. I am testing and developing a system. I went even one further
by examining binary values. Now, there is as you say some correlation. I
have had some runs of 32 to 33 1s in the data. I tested for 100 billion
itterations on various passwords. In some cases, we would find 33-35 bits of
0s or 1s. One would have to know the algorithm and plaintext and/or key to
get anywhere.
--
http://welcome.to/speechsystemsfortheblind
"John Feth" <[EMAIL PROTECTED]> wrote in message
news:01c05fbb$43b91520$[EMAIL PROTECTED]...
> Gentlemen,
>
> At the risk of jumping in late on this thread and repeating already
covered
> insights, I'd like to contribute my 2 cents worth of entropy to this
> discussion. A set that is random and non-uniform may not be very useful
in
> cryptography because on some scale a correlation between members of the
> random set exists.
>
> For example, let's say we have an arbtirarily long random string of base
10
> digits in which the digits are uncorrelated and uniformly distributed.
> This string would make a great one time pad for text messages written as
> the numerical equivalents ASCII characters. We can convert the uniformly
> distributed string to another random but non-uniformly distributed string
> using a rule that interprets each digit in the uniformly distributed
string
> as the number of 1's between 7's i.e.;
>
> the sequence 342 goes to 111711117117.
>
> This non-uniformly distributed random string would be a really cruddy one
> time pad as it would allow some ASCII values to "leak through" the pad
with
> nothing more than an offset. In the non-uniformly distributed random
> string, the occurence of a 1 is strongly correlated with the subsequent
> occurence of another 1 and the occurence of a 7 is even more strongly
> correlated with the subsequent occurence of a 1. The randomness of the
> non-uniformly distributed string lies in the uncorrelated lengths of the
> strings of 1's between 7's. (Note that we can reclaim the original
> uniformly distributed string from the non-uniformly distributed string if
> we like.)
>
> It seems to me that the only cryptographically important attribute of a
> random string is the lack of correlation at any scale.
>
> Regards,
>
> John Feth
>
>
>
> John Myre <[EMAIL PROTECTED]> wrote in article
> <[EMAIL PROTECTED]>...
> > Tim Tyler wrote:
> > <snip>
> > > The word does not have the universal precise meaning you seem to
think.
> > >
> > > For example, try http://www.io.com/~ritter/GLOSSARY.HTM#Random for
> another
> > > definition of "random".
> > <snip>
> >
> > Interestingly, Terry's definition agrees more closely with Doug
> > than with Tim. He does *not* say that random means uniformly
> > distributed. He *does* say that a random process is "ideally"
> > uniform - which for encryption is certainly true. And it also
> > shows clearly that "random" might *not* be uniform.
> >
> > JM
> >
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Thu, 07 Dec 2000 06:44:26 GMT
A company called Cloakware seems to claim that they could protect software
that decrypts, making it infeasible to extract the key being used. It's
hard to believe, but their Web site makes it sound plausible:
http://www.cloakware.com/
This wouldn't work for DVDs, though, because the key in question has to be
transmitted to the DVD player, and this can be intercepted.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:90n05t$g6i$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Hi!
> >
> > Is it possible to securely embed a private key in executable code?
> >
> > I read that the people who created DeCSS (a utility for decoding
> DVDs) were able
> > to do it because Xing failed to encrypt their key in their software.
> >
> > From this, I asume other software vendors do encrypt keys in their
> software and
> > they can't be easily extracted. What technique do they use?
> >
> > Any pointers to more information are welcome.
>
> Um it's impossible?
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Noname" <[EMAIL PROTECTED]>
Subject: Where could I find sources of crypt algorithms? (in some programming language)
Date: Wed, 6 Dec 2000 05:39:06 +0100
Where could I find sources of crypt algorithms? (in some programming
language).
Thx.
------------------------------
From: [EMAIL PROTECTED] (David Dylan)
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Thu, 07 Dec 2000 08:27:14 GMT
On 6 Dec 2000 17:01:59 -0000, [EMAIL PROTECTED] wrote:
>In nl.juridisch David Dylan <[EMAIL PROTECTED]> wrote:
>> Hoe vaak je een verkeerde pincode intikt.
>
>
>zover ik weet de bank zelf. als je twee keer verkeerd intikt en op een
>willekeurige andere plaats weer goed intikt, dan is de zaak weer
>gereset.
Thanks, dat vroeg ik mij af... :-)
--
Kijk eens op mijn community site:
http://www.grep.nu/beleggers
Of op mijn persoonlijke site:
http://www.xs4all.nl/~nobeard
------------------------------
From: "Jan Hein Mastenbroek" <[EMAIL PROTECTED]>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Wed, 6 Dec 2000 16:42:16 +0100
David Dylan <[EMAIL PROTECTED]> schreef in berichtnieuws
[EMAIL PROTECTED]
> On Wed, 06 Dec 2000 10:32:38 GMT, [EMAIL PROTECTED] (David Dylan) wrote:
>
> PS: Iemand enig idee waar dit wordt bijgehouden? Bij de bank of op de
> automaat?
>
Of op de pas?
Gr.
Jan Hein
> Groetz.
> DD.
>
>
> --
> Kijk eens op mijn community site:
> http://www.grep.nu/beleggers
> Of op mijn persoonlijke site:
> http://www.xs4all.nl/~nobeard
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Thu, 07 Dec 2000 10:56:55 +0100
Reply-To: [EMAIL PROTECTED]
Mok-Kong Shen wrote:
>
> Sorry, I erred. Since the F's are secret, the STT can be
> public.
>
> M. K. Shen
Right =)
--
==========================================
J�rgen Hedlund, Software Engineer
Ericsson Software Technology, BGw
==========================================
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering? (correction w/ addition)
Date: Thu, 07 Dec 2000 11:06:46 +0100
Reply-To: [EMAIL PROTECTED]
John Myre wrote:
>
> Jorgen Hedlund wrote:
> >
> > (correction with some additions)
> >
> > I was trying to sleep last night when I got to think of this
> > cipher algorithm. Well, not exactly an algorithm, more like
> > an idea for one.
> >
> > Imagine a statemachine, and its state transition table (STT).
> <snip>
>
> Actually, that would be a good abstract description of any
> stream cipher.
Yah? Well, this seems to be a stream cipher since it isn't a
block cipher, right? Is the definition of a stream cipher that
you only look at the current character, and doesn't need to know
any other?
> Part of the security would rest in the size of the state: if
> it is too small, the cryptanalyst could simply do a brute-force
> guess of the (initial) state. On the other hand, a large state
> means a really large STT. So any practical system uses
> computation for (at least part of) the "next state" function.
But the brute-force attack doesn't only have to guess the initial
state, since it has to guess _all_ states transitions in the STT.
I'm no mathematician, but I believe that a grid of 256 chars in
the x-axis (see the STT in my previous post), and a number of
different states (y-axis in the STT) let's say 256? Wouldn't that
produce a whole lot of combinations? (ok the key would be 256*256
bytes in size.. uhm.. 65536 bytes in size)
But each of these 65536 bytes would need a correct value (0-255)
to allow the deciphering to work. (right? or could there be any
partial deciphering?) That means, uhm, 256^65536 different
combinations of the grid, right? And I believe that is a whole
lot of combinations. Way to many to allow brute forcing...
> It might be instructional to consider a few stream ciphers
> and relate them to the state machine model. PRNG ciphers
> like RC4 don't use the plaintext or ciphertext to affect the
> state, so in the state machine model every transition is
> independant of the input. But a general "stream cipher" is
> not limited this way, and can use plaintext or ciphertext
> feedback if desired.
What do they use, if not the plaintext?
BR/jh
--
==========================================
J�rgen Hedlund, Software Engineer
Ericsson Software Technology, BGw
==========================================
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Thu, 07 Dec 2000 11:11:03 +0100
Reply-To: [EMAIL PROTECTED]
> What do you mean by a reversed STT?
The reversed STT is what you need to reverse the ciphertext.
You'll need to know where to go after you have reversed the
Fn() (ciphertext->plaintext), since it's the plaintext that
is used when traversing the STT.
Thinking further about this, wouldn't it be kind of ugly if
you have the first plaintext character wrong? I mean, the
next state (n+) would then be something completely different,
and thus causing every other plaintext character to be wrong.
Right?
BR/jh
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Smart Card vs 1.44 Disk
Date: Thu, 07 Dec 2000 10:45:01 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, John Myre wrote:
> I'd like to hear more responses on this, too. Smart cards
> are greatly popular in Europe, but not in the United States.
> Why this is I do not know, unless it be inertia.
I think it's partly inertia and partly parochialism - most smartcard
products are not of US origin.
> There is certainly one good reason for smart cards: the secrets
> can stay there, and you don't have to worry about the problem
> of insecure PC's.
You *do* have to worry about insecure PCs - just not for the same
reason. It's not possible for rogue software to steal your private key
from a smartcard, but it's still possible for a Trojan Horse program in
your PC to use your private key to sign transactions without your
knowledge - it just has to wait until you insert your smartcard and
enter your PIN.
Cheers,
Daniel.
------------------------------
From: [EMAIL PROTECTED] (David Dylan)
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Thu, 07 Dec 2000 11:26:32 GMT
On Wed, 6 Dec 2000 16:42:16 +0100, "Jan Hein Mastenbroek"
<[EMAIL PROTECTED]> wrote:
>Of op de pas?
Nee joh! Dat zou logisch zijn.
--
Kijk eens op mijn community site:
http://www.grep.nu/beleggers
Of op mijn persoonlijke site:
http://www.xs4all.nl/~nobeard
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Thu, 07 Dec 2000 12:51:45 +0100
Jorgen Hedlund wrote:
>
> > What do you mean by a reversed STT?
>
> The reversed STT is what you need to reverse the ciphertext.
> You'll need to know where to go after you have reversed the
> Fn() (ciphertext->plaintext), since it's the plaintext that
> is used when traversing the STT.
>
> Thinking further about this, wouldn't it be kind of ugly if
> you have the first plaintext character wrong? I mean, the
> next state (n+) would then be something completely different,
> and thus causing every other plaintext character to be wrong.
> Right?
You don't need a explicit reverse table, it being easy
to work with the original STT.
Of course, if one step is wrong, the following sequence of
states will gnerally be different.
BTW, I said that the STT can be public, but certainly it
can also be secret, being e.g. generated by a PRNG with
a secret seed.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Where could I find sources of crypt algorithms? (in some programming
Date: Thu, 07 Dec 2000 12:51:35 +0100
Noname wrote:
>
> Where could I find sources of crypt algorithms? (in some programming
> language).
You can find some in Bruce Schneier's AC. There are many
sites offering sources. Many links can be obtained from
e.g. www.cryptography.org. Look in particular to AES,
the future block cipher standard, at www.nist.gov/aes/
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Hamming Distance
Date: Thu, 07 Dec 2000 11:50:39 GMT
[EMAIL PROTECTED] wrote:
>
> Given a list of binary strings (256 bits each) is there an
> time-effecient way to find the set of strings within a certain hamming
> distance from each member? Currently, I'm doing a simple iteration:
>
> foreach i in list:
> remove i from list;
>
> foreach j in list:
> if (hamming(i, j) < x)
> do_something
How many strings do you tend to have? What does x tend to be? If x is
really small (like 3 or something) then you could speed things up by
throwing the strings into buckets based on the first byte, then only
comparing those strings which are close enough in the first byte. In
any case, you can abandon the software population count as soon as the
Hamming threshold is crossed.
There are a variety of techniques for fast population counting, though I
can't remember them off the top of my head. GNU MP
(http://www.swox.com/gmp/) includes a "population count" function which
is probably implemented very efficiently, so you could steal their
code. It includes the comment
/* Cool population count of a mp_limb_t.
You have to figure out how this works, I won't tell you! */
but it's pretty straightforward and I can describe it if you like.
x -= (x & 0xaaaaaaaa) >> 1;
x = ((x >> 2) & 0x33333333L) + (x & 0x33333333L);
x = ((x >> 4) + x) & 0x0f0f0f0fL;
x = ((x >> 8) + x);
x = ((x >> 16) + x) & 0xff;
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: Wei Dai Crypto++ and PGP SDK
Date: Thu, 07 Dec 2000 11:50:11 +0000
"P.C. Teo" wrote:
>
> Can anyone analyze the advantage and disadvantage of these two crypto
> library?
Can you deposit a sum of money into my bank account?
Seriously, why can't you analyze the two libraries (PGPsdk, and
Crypto++)?
We don't know your requirements, or of what benefit certain featuress
would be to you and your needs.
I think Crypto++ is better because it has a cooler name. It is also
intended for C++ usage, whereas PGPsdk is a C API the last time I
looked. PGPsdk is a commercial product, thus may have more support /
consulting options available from its supplier.
------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: Where could I find sources of crypt algorithms? (in some programming
Date: Thu, 07 Dec 2000 11:54:39 +0000
Noname wrote:
>
> Where could I find sources of crypt algorithms? (in some programming
> language).
> Thx.
C used in OpenBSD
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/crypt.c?rev=1.13
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/
C from OpenSSL
http://www.openssl.org/source/cvs/exp/crypto/des/fcrypt.c?rev=1.11&hideattic=1&sortbydate=0
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Thu, 07 Dec 2000 13:05:47 +0100
Reply-To: [EMAIL PROTECTED]
Mok-Kong Shen wrote:
>
> Jorgen Hedlund wrote:
> >
> > <snip>
>
> You don't need a explicit reverse table, it being easy
> to work with the original STT.
Hmm, you mean that the same STT could be used when reversing
the ciphertext? Gotta think about that one.
Thought a bit; I think I see your point, if the initial state
is known, you could ask the DeFn() of the ciphercharacter to
give you the plaincharacter, and then you'd know where to go.
But if the initial state is secret as well, there are 256
possibilities of a start state (you don't need to start in
state 0..). Of course, if you have the STT, then this 256
possibilities could easilly be brute forced. Better keep the
STT secret =)
> Of course, if one step is wrong, the following sequence of
> states will gnerally be different.
>
> BTW, I said that the STT can be public, but certainly it
> can also be secret, being e.g. generated by a PRNG with
> a secret seed.
That 'PRNG' abbr. I've seen alot in this NG. What the heck
is that? Or should I consult the FAQ? *lazy* =)
I can think of three possibilities of secrecy:
1) You keep the Fn()-keys secret, but the STT public.
2) You keep the STT secret, but the Fn()-keys public.
3) You keep the both secret. (I.e. the secret key would
consist of the STT and all the Fn()-keys. This would
ofcourse double the keysize (STT + 256 Fn-keys of 256
bytes each)
I haven't tried to implement this as of yet, but I think
it's interesting enough to try it. If so, I'd need a really
good random generator. I think I read something about 'Random IV',
is that such a generator? Or what is it?
Thanx for your time!
BG/jh
------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: Math background required for Cryptology ?
Date: Thu, 07 Dec 2000 12:19:45 +0000
Scott Craver wrote:
>
> M.S. Bob <[EMAIL PROTECTED]> wrote:
> >Ryan J Schave wrote:
> >>
> >> What topics in math should I have a firm grasp of before I can expect to get
> >> the most of cryptology?
> >
> >It's almost easier to just get a 4 year bachelor's degree in pure
> >mathematics.
>
> I would suggest rather a 4 year bachelor's degree in
> something else, such as computer science or electrial engineering,
> if those departments are theoretical enough.
My comment was meant to be light hearted and tongue-in-cheek. Many
cryptographers do have computer science backgrounds, a CS programme with
a heavy dose of pure math is a fine way to prepare to be a
cryptographer.
I am hesitant to suggest electrical engineering as a good background, as
I believe the majority of programmes are more practical oriented than
math- theorical.
I said 'almost easier', and I don't think that EE would make
understanding cryptology easier than a CS or Math degree.
> Information theory is often taught in electrical eng, and you're
> better off taking some other signal processing courses too.
> A course on signals and systems, a course on random processes,
Why do you recommend signal processing? I'm curious, as never having
taken a signals course.
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Math background required for Cryptology ?
Date: Thu, 07 Dec 2000 20:30:30 +0800
[EMAIL PROTECTED] wrote:
> Secret Key algorithms are much easier, you need to know basic algebra
> and modular arithmetic. Currently there's a tendancy towards using
> alternate bases (Ellyptic Curves were used in 2 AES finalists; Twofish
> and Rijndael, Rijndael was later named as AES), so it would probably be
> useful to know at least elliptic curves. If you can bring anthing else
> to the fight it's probably worth it.
Well, in order to understand how Rijndael works, and even how to
implement it properly, you'd need a basic knowledge of abstract algebra
and algebraic field theory as well. The same is true even of many other
ciphers like twofish, which also uses GF(2^8). Note that GF(2^8) as
defined in Rijndael and Twofish are not elliptic curve bases! They
simply use representations of the finite field GF(2^8) and its basic
operations. You only need elliptic curve background if you want to
implement a *public-key* system based on it.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Dec 2000 12:40:04 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
: Paul Rubin wrote:
:> I wouldn't use the term "easy" but software vendors haven't yet come
:> up with a software-only copy protection scheme that can't be cracked
:> with enough effort. [...]
: Creating a software-only copy protection scheme is actually _easier_
: than hiding a private key in your programs. Software-only copy
: protection can be achieved by placing a public key in your code. It
: doesn't matter if someone can read that key because it's a public key,
: that wouldn't help thbem at all to create their own forged credentials.
: So software-only copy protection doesn't require hiding anything, it
: just requires preventing a public key from being tampered with. Tamper
: proofing is _much_ easier than hiding.
Can you describe what this does in more detail?
How does embedding a public key in software prevent that software from
being copied?
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Hamming Distance
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Dec 2000 12:45:06 GMT
Paul Crowley <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
: There are a variety of techniques for fast population counting, though I
: can't remember them off the top of my head. [...but...]
: /* Cool population count of a mp_limb_t.
: You have to figure out how this works, I won't tell you! */ [...]
: x -= (x & 0xaaaaaaaa) >> 1;
: x = ((x >> 2) & 0x33333333L) + (x & 0x33333333L);
: x = ((x >> 4) + x) & 0x0f0f0f0fL;
: x = ((x >> 8) + x);
: x = ((x >> 16) + x) & 0xff;
Much the same code may have been invented more than once:
#define BITCOUNT(x) (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255)
#define BX_(x) ((x) - (((x)>>1)&0x77777777) \
- (((x)>>2)&0x33333333) \
- (((x)>>3)&0x11111111))
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Where could I find sources of crypt algorithms? (in some programming
Date: Thu, 07 Dec 2000 20:44:25 +0800
Noname wrote:
>
> Where could I find sources of crypt algorithms? (in some programming
> language).
> Thx.
Another place:
http://ftp.funet.fi/pub/crypt/
all sorts of algorithms here.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Fips Pub 140-1 and RNG
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Dec 2000 12:48:27 GMT
[EMAIL PROTECTED] wrote:
: Also, what is the relevance of these tests being done on power up as
: mentioned in the FIPS 140 document ?
Random numbers are often required for "Power On Self-Test"s (POSTs).
Could that have been what the document was talking about?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Wei Dai Crypto++ and PGP SDK
Date: Thu, 07 Dec 2000 12:46:25 GMT
In article <90n1si$phu$[EMAIL PROTECTED]>,
"P.C. Teo" <[EMAIL PROTECTED]> wrote:
> Can anyone analyze the advantage and disadvantage of these two crypto
> library?
>
> Which is better?
Why are you people constantly asking "which is better". That is such a
vague and unanswerable question.
What are your requirements, restrictions, prefererences, platforms,
etc...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Thu, 07 Dec 2000 12:47:35 GMT
In article <elGX5.39628$[EMAIL PROTECTED]>,
"Matt Timmermans" <[EMAIL PROTECTED]> wrote:
> A company called Cloakware seems to claim that they could protect
software
> that decrypts, making it infeasible to extract the key being used.
It's
> hard to believe, but their Web site makes it sound plausible:
>
> http://www.cloakware.com/
>
> This wouldn't work for DVDs, though, because the key in question has
to be
> transmitted to the DVD player, and this can be intercepted.
Yeah I know, I work for cloakware.
Tom
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
******************************
