Cryptography-Digest Digest #666, Volume #11 Sun, 30 Apr 00 02:13:01 EDT
Contents:
Re: How would a 15 year old start? (David Formosa (aka ? the Platypus))
Re: How safe am I using a subset of the bytes returned by SHA-1? (stanislav shalunov)
Re: Intel drops serial number (Isaac)
S/MIME + Netscape v47 serious problem in symmetric encryption ... (jungle)
Hushmail style idea (Tom St Denis)
Tempest Attacks with EMF Radiation ("Ryan Phillips")
Re: The Illusion of Security (Uri Blumenthal)
Re: Extending the sboxgen and differential analysis (David A. Wagner)
Mathmatical concepts (Ryan Senior)
Re: Intel drops serial number (David A. Wagner)
Re: sboxes for the bored... (David A. Wagner)
Re: Mathmatical concepts (David A. Wagner)
Re: sboxes for the bored... (David A. Wagner)
Re: sboxes for the bored... (David A. Wagner)
What is the strongest encryption rate so far possible/achived? ("Monolo")
Re: What is the strongest encryption rate so far possible/achived? (David A Molnar)
Re: Tempest Attacks with EMF Radiation (Guy Macon)
Re: How safe am I using a subset of the bytes returned by SHA-1? (Mark Thomson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: How would a 15 year old start?
Date: 30 Apr 2000 01:14:27 GMT
Reply-To: dformosa@[202.7.69.25]
On Sat, 29 Apr 2000 09:34:42 -0700, Monolo <[EMAIL PROTECTED]> wrote:
>As I said, in my pervious post, I would love to learn, I read Tom's post
>back to me after I sent it, sorry for the duplication. I was wondering, what
>would be the best way to start? Are there any good online resources?
Buy Applied Cryptography By Bruce Schneier.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Interested in drawing platypie for money? Email me.
------------------------------
Subject: Re: How safe am I using a subset of the bytes returned by SHA-1?
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sun, 30 Apr 2000 01:20:04 GMT
Mark Thomson <[EMAIL PROTECTED]> writes:
> I'm coding up a shell extension for Win32 platforms that will show a
> hash for a file when you right click on it.
How would this be used?
> I'm using SHA-1, for the simple reason that I have source to it, and
> it works. The problem with SHA-1 is that it's a bit on the chatty
> side: it produces 20 bytes of digest, which equates to 40 characters
> when printed in hex, plus some formatting to make it readable.
You can use base64; that'll make it 27 characters.
> I am very tempted to simply take the first 8 bytes of the digest, and
> display them in this format:
> xxxx-xxxx xxxx-xxxx
> since this is a managable amount of data for a context menu addon.
Is the user supposed to memorize 64 random bits? I've been trying in
vain for years to make users memorize 56 bits. They won't.
This data will be cut-and-pasted only. So, why bother with size?
> Given that the security of the entire western world won't be riding on
> this app, how much danger am I in doing this. The naive answer is
> 2^64, since I have 64 bits of data, which in all honesty is plenty
> enough for what I'm doing. However is there something that I don't
> know that could cause problems?
If you have 2^32 files, it's probable that you'll have a collision.
Whether this matters for your application, I don't know.
It's also possible to modify a file and make it have the same checksum
(though it's going to take a few hours to do so).
> As an alternative, is there any reason not to drop back to the CCITT
> CRC32, which produces only 4 bytes of output? That'd give me a 1 in 4
> billion (give or take) chance of a false match, which again is
> probably plenty enough for what I'm doing.
If the possibility of somebody changing the file without changing
checksum doesn't bother you, it's OK. It's also not a one-way
function, so information is leaked.
--
stanislav shalunov | Speaking only for myself.
------------------------------
From: [EMAIL PROTECTED] (Isaac)
Crossposted-To: talk.politics.crypto
Subject: Re: Intel drops serial number
Date: Sun, 30 Apr 2000 01:29:45 GMT
On 29 Apr 2000 10:23:37 -0600, Vernon Schryver <[EMAIL PROTECTED]> wrote:
>
>The evil is that the kooks fooled the clue-free masses into thinking
>that they were protecting their privacy by fighting the PIII ID.
>The idiot masses were distracted from real and quite serious privacy
>threats. If I were paranoid, and if I didn't know that the kooks
>do such evil for free, I'd suspect that Doubleclick and the FBI
>had tricked Intel into making it's silly noises and then funded
>
I think this is the silly idea. Nobody let Doubleclick get away
with anything by distracting them with the CPU ID smoke. If anyone
was guilty of distracting people it had to be Intel. Exactly why
the kooks get some much credit when at worst they were guilty of
falling for Intel's hype is really what I think you fail to explain.
Even if other methods are more efficient, I think having a company as
large as Intel openly ignoring and publicly challenging your right for
privacy for the purpose of making a buck is something that just can't
be ignored. Neither should we ignore those company's and organizations
that fell over backwards to support the idea, or to tell us that we
should "get over" or need for privacy.
>
>The privacy problems in tracking people are not mere "potential" and have
>nothing to do with the PIII ID. By implying that some privacy was
>threatened by the PIII ID and protected by its disappearance, you are
No one has suggested that it's disappearance ends the battle. When I see
someone standing up to take the credit and annointing himself as the
"privacy president" or some such then I'll agree that we're being tricked
the way you say, but I don't see it.
Isaac
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss
Subject: S/MIME + Netscape v47 serious problem in symmetric encryption ...
Date: Sat, 29 Apr 2000 21:38:42 -0400
THIS IS VERY SERIOUS BREACH OF SECURITY, BY USING SOMETHING, WHICH I DIDN'T
APPROVE
S/MIME + Netscape v47 serious problem in symmetric encryption ...
S/MIME v2 Message Spec has 4 rules to step down in symmetric encryption, but
the rules are for ambiguity only situations ...
tested with win95 + netscape v47 / 128 bits ...
example 1
==========
at creation process of this message [ at test time, here is reporting problem
only ], I selected explicitly RC2 / 128 bits
cipher only, I need all of my s/mime encryption to be made with RC2 / 128 bits,
this is my requirement for testing ...
but message is reporting RC2 / 40 bits encryption cipher used ...
what is going on at s/mime encryption ?
it's look to me that all is working against any logic, against any of my
selections, against my setup ...
example 2
==========
after explicitly excluding all but one cipher [ rc2/128 bits ] for s/mime
encryption,
the received message in Netscape is reporting as been encrypted by the
algorithm DES-EDE3-CBC with 168 bits & not the one that has been selected ...
how this happen ?
this cipher has been excluded from use at encryption process ...
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Hushmail style idea
Date: Sun, 30 Apr 2000 01:52:02 GMT
Wouldn't it be possible to implement a hushmail style email program if
the private key is simply derived from a password?
Just ideas...
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://tomstdenis.n3.net/search.html, it's entirely
free
and there are no advertisements.
------------------------------
From: "Ryan Phillips" <[EMAIL PROTECTED]>
Subject: Tempest Attacks with EMF Radiation
Date: Sat, 29 Apr 2000 20:51:50 -0700
I made my journey today to a local computer store and came across a device
called X-ion (www.x-ion.org). They claim that their little stick on
'modules' will reduce EMF radiation by reversing the ion particles found in
EMF. Can one place these on their monitor to prevent a tempest attack?
Thanks for the help.
-Ryan Phillips
====== 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: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Sun, 30 Apr 2000 00:21:46 -0400
Reply-To: [EMAIL PROTECTED]
> > The NSA examined the design for the cipher that was to be
> > DES. They suggested new S-boxes, and suggested reducing the
> > keyspace to 56 bits. To my knowledge they made no other
> > recommendations.
Interesting, though not accurate.
I didn't realize you were present at those confidential
discussions...?
> > The round keys are quite independent,....
Reading this I wonder, if we are talking about the
same DES. To me if a round key bits are taken with
no alteration out of 56 "generator key" bits, it
hardly speaks of independence.
> > .....the s-boxes are protected against differential
> > analysis.
Reasonably so.
> > The decision was based on the fact that the underlying
> > algorithm could offer no more than 56 bits of security.
The key size was dictated by the hardware limitations of
that time (chip size, manufacturing costs).
> > The key space reduction to 56 bits was the smart decision,
No, it was technically necessary. Think number of gates
on the chip.
> What facts are you basing this on? The "56-bit security"
> is taken from the small key.
Well, AFAIK he didn't base it on facts, just rumors...
> The only known attacks (linear and diff cryptanalysis)
> are not pratical, which means independant keys can get
> you up to (*) 768 bits of practical security.
Increasing the number of key bits but leaving the number of
rounds the same (16) won't give full 768 bits of security, rather
something like 2^62 for differential, about 2^60
for linear (and 2^60 known-plaintext pairs); plus it's
royal pain to carry around a key 768 bit long. It of
course will blow exhaustive search out of the water
but at the same time it opens the cipher widely to
related-key attacks. [And no, you can't ignore
attacks like differential either.]
A practical solution is to (a) use PSEUDO-independent
subkeys, generated securely from a smaller user key
[something between 64 and 128 bits, for example],
and (b) increase the number of rounds to at the
very least to 24, preferably to 32. This will
make differential and linear attacks impossible,
related-key attacks are excluded because users
can't directly set the subkey bits (they can
request a change, but cannot tell how to
aler the user key to cause a desired
change in any generated subkey)...
Forgive the plug - that's exactly what we did in
DES-SK.
> Maybe some others should comment on this, and I suggest
> you read "Differential Cryptanlysis of DES-Like systems"
> by Eli Biham (&) which covers this in detail.
Yes, an excellent book.
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Extending the sboxgen and differential analysis
Date: 29 Apr 2000 20:50:24 -0700
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> If I wanted to extend my sboxgen program to test for differential
> characteristics... Could I use the following code?
>
> (for n by n boxes)
> for x = 0 to n
> for y = 0 to n
> DT[F(x) xor F(x xor y)] += 1
You want DT[y]F(x) xor F(x xor y)] += 1.
Also, a S-box with n-bit inputs has 2^n possible input values,
so you probably want x and y to range over all of them
(if that isn't already what you are doing).
Finally, the y=0 case doesn't tell you anything; start from y=1.
------------------------------
From: Ryan Senior <[EMAIL PROTECTED]>
Subject: Mathmatical concepts
Date: Sat, 29 Apr 2000 23:35:54 -0500
If one were to comprise a short list of mathmatical concepts that if one
were to grasp, would greatly enhance his ability to do cryptography?
Right now I am in my second semester of calculus and have access to a
few math teachers that i know would be willing to help me with a few
things, if i know what they were, because i am pretty interested in
creating cryptographic algorhythms.
thanks
Ryan
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Crossposted-To: talk.politics.crypto
Subject: Re: Intel drops serial number
Date: 29 Apr 2000 20:58:42 -0700
In article <8ecpc0$jod$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
> Only
> kooks, the extremely ignorant, and those with unstated political or other
> axes to grind could have ever claimed that the PIII ID in the chip could
> affect anyone's privacy. There are so many other globally unique computer
> ID's are avaliable and in current use that while the PIII ID would have
> been quite handy, it was not significant.
Perhaps you overlooked the rest of what Intel was proposing?
It was easy to miss the details, with all the hype.
Anyway, the proposal was far more than *just* making a identifier
available -- Intel was proposing this as one part of a whole framework
that included web browsers that routinely transmitted the PIII ID,
web sites that only allowed access to computer sending their PIII ID,
and so on.
Bottom line: This was a pretty privacy-unfriendly proposal, and one
that rightly deserved criticism.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: sboxes for the bored...
Date: 29 Apr 2000 21:00:49 -0700
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> However, there are apparently different measures of nonlinearity;
> are they strictly equivalent?
Can you mention one? I could be confused, but I *think* the definitions
of nonlinearity I've seen in published papers all agree with Ritter's
definition. I'd be happy to be educated, though...
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Mathmatical concepts
Date: 29 Apr 2000 21:05:19 -0700
In article <[EMAIL PROTECTED]>,
Ryan Senior <[EMAIL PROTECTED]> wrote:
> If one were to comprise a short list of mathmatical concepts that if one
> were to grasp, would greatly enhance his ability to do cryptography?
This has been discussed here before, but the short answer is: Discrete math.
(Linear algebra, group theory, number theory, combinatorics, graph theory,
probability, statistics, theoretical computer science, and so on.)
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: sboxes for the bored...
Date: 29 Apr 2000 21:06:44 -0700
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Question: what is the diff between linear/affine?
f(x) = Mx is linear, f'(x) = Mx+b is affine.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: sboxes for the bored...
Date: 29 Apr 2000 21:11:16 -0700
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I dunno what he is talking about the walsh transform (taken from "On
> linear cryptanalysis") will give you a negative when the function is
> affine, a positive when it's linear and close to zero if it's neither.
I'm not quite sure what you're trying to say here,
but I fear that the above is so mistaken it's "not even wrong".
------------------------------
From: "Monolo" <[EMAIL PROTECTED]>
Subject: What is the strongest encryption rate so far possible/achived?
Date: Sat, 29 Apr 2000 21:56:18 -0700
Just curious? Anyone know?
JJ
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: What is the strongest encryption rate so far possible/achived?
Date: 30 Apr 2000 05:17:00 GMT
Monolo <[EMAIL PROTECTED]> wrote:
> Just curious? Anyone know?
What do you mean by "strongest encryption rate" ?
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Tempest Attacks with EMF Radiation
Date: 30 Apr 2000 01:33:37 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Ryan
Phillips) wrote:
>
>I made my journey today to a local computer store and came across a device
>called X-ion (www.x-ion.org). They claim that their little stick on
>'modules' will reduce EMF radiation by reversing the ion particles found in
>EMF. Can one place these on their monitor to prevent a tempest attack?
I am an Electrical Engineer who has designed products that passed tests
for Tempest (which was interesting, considering that my security clearance
at the time did not allow me to read the Tempest specification!).
The device in question is a fraud, plain and simple. It will not have
any effect on the amount of EMF or the amount of ions in the air.
I would be glad to have a brief discussion about more effective measures,
but to do so I need to know what kind of attacker you are trying to stop.
------------------------------
From: Mark Thomson <[EMAIL PROTECTED]>
Subject: Re: How safe am I using a subset of the bytes returned by SHA-1?
Date: Sat, 29 Apr 2000 22:50:24 -0700
On Sun, 30 Apr 2000 01:20:04 GMT, stanislav shalunov
<[EMAIL PROTECTED]> wrote:
>Mark Thomson <[EMAIL PROTECTED]> writes:
>
>> I'm coding up a shell extension for Win32 platforms that will show a
>> hash for a file when you right click on it.
>
>How would this be used?
I'm doing it as a standard context menu extension DLL. When a user
right clicks on a file in the Win32 world, a context menu is presented
that contains useful things to do to the file. By writing a suitable
DLL, and notifying the system of it's existance via the registry, it's
possible to add entries to this menu. Since I get to pick and chose
the text of the menu entry I add, I simply compute the SHA of the
file, and format it into the string that becomes the menu entry.
>Is the user supposed to memorize 64 random bits? I've been trying in
>vain for years to make users memorize 56 bits. They won't.
Touche. I have a fairly good memory for numbers, but even 8 bytes
worth (i.e. 16 hex digits) is too much for me.
>This data will be cut-and-pasted only. So, why bother with size?
Now that is a *GOOD* idea. I like this a lot. It ought to be close
to a no-brainer to provide an option to park the SHA in the clipboard,
and / or compare with the current clipboard contents.
>If you have 2^32 files, it's probable that you'll have a collision.
>Whether this matters for your application, I don't know.
In the place where it's highly likely to find use, this probably won't
be a major concern. What got me started on this was looking for a
very fast way to determine if a file in our source code repository is
different from the base that I'm working from. That would indicate
someone else has checked in some changes (we have non-exclusive
checkouts), which in turn means I will need to merge their changes
with mine at my checkin time. Typical changes in this sort of setup
will (I hope) give a different SHA / CRC32 / whatever.
>It's also possible to modify a file and make it have the same checksum
>(though it's going to take a few hours to do so).
Again, in my envonment, it is *EXTREMELY* unlikely that someone is
going to do this on purpose.
>> As an alternative, is there any reason not to drop back to the CCITT
>> CRC32, which produces only 4 bytes of output? That'd give me a 1 in 4
>> billion (give or take) chance of a false match, which again is
>> probably plenty enough for what I'm doing.
>
>If the possibility of somebody changing the file without changing
>checksum doesn't bother you, it's OK. It's also not a one-way
>function, so information is leaked.
I'd kinda figured it was a many-to-one function. My reasoning went
like this. If I have a 4 byte crc, then there are 2^32 possible
values. I can trivially create 2^32 + 1 different files, therefore I
am guaranteed at least on collision from this fileset. The bottom
line seems to be that it'll work with sufficient safety for my needs.
Thanks to all for your help.
------------------------------
** 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
******************************
