Cryptography-Digest Digest #284, Volume #13 Wed, 6 Dec 00 16:13:01 EST
Contents:
Re: File Deleter/Nuker ? (Steve Portly)
Re: Smart Card vs 1.44 Disk ("Paul Pires")
Re: [Question] Generation of random keys (David Schwartz)
Re: hardware RNG's ("John Feth")
Re: Smart Card vs 1.44 Disk (lcs Mixmaster Remailer)
Re: ---- Are AES algorithms export restricted? (Simon Johnson)
Re: [Question] Generation of random keys ("Paul Pires")
Re: Math background required for Cryptology ? ([EMAIL PROTECTED])
Re: hardware RNG's ("Paul Pires")
Re: ---- Are AES algorithms export restricted? (Mok-Kong Shen)
Re: Journal of Craptology (Mok-Kong Shen)
Re: Math background required for Cryptology ? (Scott Craver)
----------------------------------------------------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: File Deleter/Nuker ?
Date: Wed, 06 Dec 2000 14:11:44 -0500
John Hairell wrote:
> On Sat, 02 Dec 2000 20:15:19 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote:
>
> [stuff snipped]
>
> >Most of the time hard disks are so dense that writing over the data
> >once is often enough. "Multi-pass" file wipers are just plain paranoia
> >food. On floppy disks your best bet is to burn them since they are
> >cheap. But because hard disks store information so densely the
> >probability of left over data is next to nill.
>
> The US government requires that hard drives containing classified data
> be overwritten at least seven times prior to destruction. It might be
> surmised that the number seven wasn't just picked at random. Perhaps
> they know something you don't.
>
> Also, certain investigative organizations of the US government possess
> (and use) hardware that reads wiped drives. Perhaps they know
> something you don't.
>
> John Hairell ([EMAIL PROTECTED])
Whether you use one or eight this program runs pretty quick.
Modift it to overwrite different characters if you like.
#include <stdio.h>
#include <io.h>
main()
{
FILE *fil;
long len = 0;
char achar;
int count;
if ((fil = fopen ("fileofchoice", "rb")) == NULL) return 0;
while( !feof( fil ) )
{
fread(&achar, sizeof(unsigned char), 1, fil);
len = len + 1;
}
fclose (fil);
for(count = 0; count < 8; count++);
{
flushall();
if ((fil = fopen ("fileofchoice", "r+b")) == NULL) return 0;
while (len)
{
fputc ('~', fil);
-- len;
}
fclose (fil);
flushall();
}
/*remove (sourcefile); */
return 1;
}
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Smart Card vs 1.44 Disk
Date: Wed, 6 Dec 2000 11:11:08 -0800
David Schwartz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Anonymous wrote:
>
> > One big difference. A smart card can Prove something by what it can do with
> > a secret that it has. In effect, it can prove knowledge of the secret
without
> > revealing it.
>
> In addition, a smart card can act as a vault for information, releasing
> only specific bits of information in response to specific requests.
> Different access codes can be required for different sets of
> information. So I can enter a code into a machine that takes my smart
> card that only allows the machine to do only some specific set of things
> with the credentials in my smart card.
It also lets you play with time and sequence. You can make someone
commit to the transaction before they validate it.
The user:
Picks a "Secret" salt to be used with the key.
Sends the transaction encrypted with this composite.
The Autority picks a random message, encrypts it
and sends it to the card.
The card decrypts it and uses the plaintext as a salt
to encrypt the first "Secret" salt.
(If it was decryped with an unknown key, the Authority will not know
what this user constructed plaintext is)
The authority decrypts the second message, it now has the the first
salt and decrypts the transaction.
Both the user and the authority prove they know a secret
AFTER the transaction has been committed to and transmitted.
Both get to pick a contemporary secret to make sure the event
is current and not replayed.
Don't know why you'd want to do this but it is another
example of the difference between locked static storage
and active participation.
Paul
>
> DS
====== 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: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Wed, 06 Dec 2000 11:48:48 -0800
Benjamin Goldberg wrote:
> Umm, Alan is saying that it's impossible to algorithmically perform a
> real-world physical act. Code can simulate a coin flip, but not
> actually do one. Anyone who believes that they can algorithmically
> generate random number is in a state of sin. (Name that quote!)
By what definition of "random" is it impossible to algorithmically
convert non-random numbers into random ones?
You would have to accept biased numbers as random, no matter how heavy
the bias, because you can algorithmically remove bias.
You would have to accept correlated numbers as random, because you can
algorithmically remove correlation.
In fact, you would have to accept practically anything that was to any
extent unpredictable as "random". Because unpredictability is the _only_
thing you can't create algorithmically.
DS
------------------------------
From: "John Feth" <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: 6 Dec 2000 19:26:05 GMT
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
>
------------------------------
Date: 6 Dec 2000 20:00:27 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Smart Card vs 1.44 Disk
John Myre writes:
> 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.
Smart cards are beginning to take off in the US. In the past they have
not been necessary because there was a widespread infrastructure of mag
stripe credit cards. However now the smart cards are being positioned
as for Internet purchases. Just plug in your card and you won't have
to enter your credit card number at each site.
American Express has had their Blue card out for a year or so now.
Two weeks ago I got a mailing from a Visa company with a smart card.
Two days ago I saw a commercial for a different Visa smart card.
Maybe 2001 will be the year of the smart card in the US.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: ---- Are AES algorithms export restricted?
Date: Wed, 06 Dec 2000 19:56:58 GMT
In article <wGqX5.3809$I5.28736@stones>,
"Brian Gladman" <[EMAIL PROTECTED]> wrote:
>
> "Greggy" <[EMAIL PROTECTED]> wrote in message
> news:90jucc$ik$[EMAIL PROTECTED]...
> > It just seemed to me as I was reading another post here that none of
> > the AES algorithms could possibly be export restricted from within
the
> > US since they were all published during the AES contest. Am I
> > correct? Or did I miss something in my thinking here?
>
> You are correct in respect of 'public domain' source code but the
situation
> in respect of actual implementations is more complex.
>
> For example, it seems unlikely that a high grade AES implementation in
> hardware would be free of export controls from the ***US***.
>
> But things have changed a lot recently so even this might now be
possible -
> I am not up to date on where things stand in the US.
>
> Brian Gladman
>
>
Yes, but i can export the circuit diagrams right?
I hate these laws, they are really stupid..... It doesn't stop us from
distributing Crypto.... it just makes it annoying.
RIP is non-sensical -> If i claim my cipher-text was encrypted using
the OTP then they are forced to cryptoanalyse the underlying algorithm
to prove me incorrect (which is infeasible for any good algorithm). How
on earth can they enforce this notion?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Wed, 6 Dec 2000 12:10:11 -0800
David Schwartz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
<Snip>
> In fact, you would have to accept practically anything that was to any
> extent unpredictable as "random". Because unpredictability is the _only_
> thing you can't create algorithmically.
>
> DS
It seems to me that the only detectable difference between random and
pseudo-random is that in random, needed information is
"provably unknowable" whereas in pseudo, needed information is
"required to be secret". I think this is true regardless of the purity
or unbiasedness of the "Randomness" It also seems to
me that proving algorithms cannot create unpredictability
would be as hard as proving that a source was truly random.
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]
Subject: Re: Math background required for Cryptology ?
Date: Wed, 06 Dec 2000 20:24:57 GMT
In article <BhgX5.134660$[EMAIL PROTECTED]>,
"Ryan J Schave" <[EMAIL PROTECTED]> wrote:
Here's my estimates. If you want to go into Public Key systems, you're
going to need massive amounts about number theory. The evidence of this
is very clear when you look at the very small number of base
algoroithms. Only 3 come to mind, DH, RSA, and NTRU, all the others
seem to be just variations (I've left out the roadside littered with
knapsack algorithms) just ways of doing padding, or in a different type
of math (e.g. ellyptic curves).
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.
An ability to prove a mathematical statement is almost a must. Just to
verify that you can, prove that an encryption algorithm like DES must
not have any two pairs such that DES(input1, Key) = DES(input2, Key)
where key is the same value in both, it's a very easy proof (if you
have to cheat and ask you probably don't have the knowledge yet to be
very good).
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Wed, 6 Dec 2000 12:24:47 -0800
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.)
Now wait a minute. That's not "converting" back and forth, It's inflating
and deflating Try your example where the "coverted" set is the same size,
in the same base as the source. It seems to me that you are just saying that
an amount of "randomness" will not change if you store it in a really porous
fashion.
Paul
>
> 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
> >
====== 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: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: ---- Are AES algorithms export restricted?
Date: Wed, 06 Dec 2000 21:28:05 +0100
Richard Heathfield wrote:
>
> Presumably, some enterprising Irishman has a Website offering amazingly
> secure crypto products to anyone in the world, at very reasonable
> prices. :-) If not, why not? And if so, then the American restrictions
> seem particularly pointless.
The softening of the restrictions was at least partly a
result of business competitions, I guess.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Journal of Craptology
Date: Wed, 06 Dec 2000 21:28:11 +0100
Mike Rosing wrote:
>
> Mok-Kong Shen wrote:
> > Sorry for my ignorance. What is 'forward security'?
>
> It means that if an attacker can crack your key for this message, he
> can't use anything he's learned to crack the key to the next message.
> It also applies backwards, but I don't really understand why that's
> called "forward". The main point is that each key requires the same
> amount of effort to find.
Thanks for the explanation. But that condition is normally satisfied
through employing sufficiently unpredictable
random keys, isn't it?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: Math background required for Cryptology ?
Date: 6 Dec 2000 20:53:00 GMT
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?
>
>I suggest you start with: statistics, number theory, abstract algebra,
>information theory, complexity, algorithm analysis (CS topic).
>
>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.
You'd take statistics, number theory, and abstract algebra from
the math department, 1 semester each to cover what most crypto
people need; in my case my 1st semester of abstract algebra
covered number theory all the way up to RSA. Of course more
math is desirable, especially if one is going to focus on
public-key cryptography in particular.
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,
_then_ information theory. Those first 2 are REALLY important.
Again, more is better; even courses on unrelated stuff, like
wireless, are just wonderful for crypto people. And it will
not hurt your marketability in the upcoming years.
Complexity and algorithm analysis would probably be found in
the CS program, and so would learning how to program. Further,
the math requirements of a CS program might have you taking
discrete math courses up to abstract algebra. A course on
discrete math would definitely have you prepared for the higher
math.
AFAICT the one real advantage of majoring in math rather than
EE-CS is that you take enough higher math to really understand
and have drilled into your head the concept of rigor.
-S.
------------------------------
** 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
******************************
