Cryptography-Digest Digest #106, Volume #11 Sat, 12 Feb 00 13:13:01 EST
Contents:
SHA1 and longer keys? ([EMAIL PROTECTED])
Re: PKI's and CA's ("Lyal Collins")
Re: Fwd: Anyone feel like joining a cool DeCSS related project? (Lincoln Yeoh)
Re: Twofish vs. Blowfish (Daniel S. Riley)
Re: Does the NSA have ALL Possible PGP keys? (Sander Vesik)
Basic Crypto Question 2 ([EMAIL PROTECTED])
Re: encryption export question (Frank Hecker)
Re: Which compression is best? (Tim Tyler)
Re: Basic Crypto Question 2 (Sandy Harris)
YACM - Yet Another Chaining Mode (Sander Vesik)
Re: Basic Crypto Question 2 (Mok-Kong Shen)
Re: Which compression is best? (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: SHA1 and longer keys?
Date: Sat, 12 Feb 2000 14:04:38 GMT
Hi there!
I'm a newbie to encryption and was wondering if the following method in
VisualBasic to get larger keys using a HMAC_SHA1 class from another
devloper is secure —— assuming that HMAC_SHA1 does what it is supposed to
do and that the sessionkey array [1..8] each contain 20 bytes of high
entropy random data:
For i = 2 to 8
result = HMAC_SHA1(password, sessionkeys(i)+HMAC_SHA1(password, result+
sessionKeys(i-1)))+result
Next
returns 160 bytes I use as key. password is the literal password string.
Is this secure at all? If not, what's the best way to get a larger key
than the result of SHA1?
Thanks,
John Stein
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: PKI's and CA's
Date: Sat, 12 Feb 2000 10:31:44 +1100
in answer to 2:
Since the Private key associated with your Public Key is protected by a
password, you can't improve protection using software.
Embedded systems, such as a smartcard, can perfrom a more robust password
verification than can be acheived in software, provided password-entry
protection is implemented in the embedded hardware. A tamper-evident
PINpad/reader, or possibly a tamper evident, type approved biometrics
sensor/reader combination may do the trick.
But, we are all stuck with passwords for now.
What the public/private key is used for after your password is verified is
immaterial if the password is compromised or spoofed, especially on second
or sunsequent logons.
lyal
[EMAIL PROTECTED] wrote in message <880lq7$t8g$[EMAIL PROTECTED]>...
>I am trying to understand PKI and the role of the
>CA's, toolkits etc. Here are a few of my queries,
>can any one help?
>
>1) To have use PKI technology you need CSP's.
>Where do these come from (not who makes them). Do
>they get installed when you go to the CA?
>
>2) When logging on to send a secure message how
>can the computer verify that it is you by any
>more than a password and therefore bypass the
>main problem that "passwords are notoriously easy
>to crack".
>
>3) When a secure message is sent is everything
>verified with the CA at the time? And the
>recievers CA?
>
>4) do CA's sell the "middleware" or "toolkits" so
>the PKI may be used across applications
>
>As you can probably tell I am rather confused!
>Any help oon any of these issues or other related
>issues that you think are important would be very
>much appreciated.
>
>Thank you
>
>Philly
>
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To: comp.security.pgp.discuss
Subject: Re: Fwd: Anyone feel like joining a cool DeCSS related project?
Date: Sat, 12 Feb 2000 16:15:56 GMT
Reply-To: [EMAIL PROTECTED]
How about looking at
http://personal.sip.fi/~lm/c2txt2c/
It makes for weird reading tho :). I prefer reading C to that "english".
On Fri, 11 Feb 2000 03:42:33 +0100, [EMAIL PROTECTED] (Tony L. Svanstrom)
wrote:
>------- Begin Forwarded Message -------
>
>Subject: Anyone feel like joining a cool DeCSS related project?
>From: Omri Schwarz <[EMAIL PROTECTED]>
>Newsgroups: comp.lang.perl.misc
>Date: Thu, 10 Feb 2000 20:39:58 -0500
>
>I'm writing a script that converts ANSI C code
>into English sentences that are reasonably descriptive of what
>the code is doing. The purpose is to demonstrate that
>computer code is a form of expression. By composing
>a "recipe book" out of a piece of C code (like the DeCSS code),
>one can then distribute it in a free-speech-protected form and
>convert it back to C upon recepit.
Anyway, DeCSS is already like erm everywhere.
What's this "free speech" thing? Might be even a good idea... How about USA
be the first to do this "free speech" thing? ;)
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (Daniel S. Riley)
Subject: Re: Twofish vs. Blowfish
Date: 12 Feb 2000 11:26:56 -0500
David Hopwood <[EMAIL PROTECTED]> writes:
> Eric Lee Green wrote:
> > John Myre wrote:
> > > Why wouldn't it be legal to use during development? AFAIK, patents
> > > are only relevant once you start to sell it (or the equivalent).
>
> More precisely to distribute it (free products can infringe patents), or
> to use it to provide a service to others.
>
> > No. Mere possession of a patented item without a license is illegal,
> > whether or not you intend to sell such item.
>
> This is wrong; implementation of patented technology for your own use or
> during development is not illegal, under most countries' patent laws
> (including EU countries and the US).
USC Title 35 section 271[1]:
(a) Except as otherwise provided in this title, whoever without authority
makes, uses, offers to sell, or sells any patented invention, within the
United States or imports into the United States any patented invention
during the term of the patent therefor, infringes the patent.
I don't see anything in the rest of the section that allows
implementation for your own use. I also don't see possession listed
there--use is, but not possession. Nor do I see distribution, but
distribution might be covered by
(b) Whoever actively induces infringement of a patent shall be liable as
an infringer.
[1] http://www4.law.cornell.edu/uscode/35/271.html
--
Dan Riley [EMAIL PROTECTED]
Wilson Lab, Cornell University <URL:http://www.lns.cornell.edu/~dsr/>
"History teaches us that days like this are best spent in bed"
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: 12 Feb 2000 16:26:20 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Highdesertman wrote:
>> I'm sure somebody will correct me if I'm wrong, but isn't that one of
>> the mandates that the NSA is tasked with in the first place?
> Which? You posted a lot of stuff.
> You can read about NSA's mission on their Web page. Basically,
> it is to protect US government communications and to obtain
> intelligence by analyzing signals of foreign governments.
> They definitely are not tasked with listening to every telephone
> conversation.
Hah. So how do the known cases of business intelligence (against
companies of allied nations) as outlined in the various EU documents
qualify?
--
Sander
There is no love, no good, no happiness and no future -
these are all just illusions.
------------------------------
From: [EMAIL PROTECTED]
Subject: Basic Crypto Question 2
Date: Sat, 12 Feb 2000 16:50:42 GMT
1.Which are the Top 5 PRNG's for practical cryptosystems?
2. Is there a Universal Tester to test the top 5 for Randomness?
3. Is it possible to test that a Crypto system is generating truely
random keys...and the PRNG has not been chilled ??...Difficult task
huh..with all the possible combination of keys..
4. What about using PRNG's based on thermodynamics and random motion of
molecules...or a theoretical model of some other natural random
phenomena ....
5. Has any vendor come up with a Physical Random Number generator box
... white heat ..whatever, which sits on a network suppleying random
numbers to client machines on a wan/lan?.. Need some kind of a tamoer
proof secure box...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Frank Hecker <[EMAIL PROTECTED]>
Subject: Re: encryption export question
Date: Sat, 12 Feb 2000 17:27:41 GMT
Paul Koning wrote:
> Is ciphersaber open source? If so, it looks like you could use the
> open source rules, which are pretty open...
The open source rules are pretty open only if what you are exporting is
source code. If you are exporting binaries generated from open source
code then the regulations treat them essentially the same as binaries
generated from proprietary source code. It's still possible to export
the binaries in most cases, but you have to worry about things like
"retail" vs. "non-retail" status, whether it's a "toolkit" or not,
whether it presents an "open cryptographic interface" or not, and so on.
If this is being done in a commercial context then definitely it's worth
consulting a lawyer with expertise in this area.
Frank
--
Frank Hecker work: http://www.collab.net/
[EMAIL PROTECTED] home: http://www.hecker.org/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 17:39:11 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
:> 1) From a security perspective, how important is compression? Is
:> prior compression just a kind of "weak enhancement" or is it
:> considered an integral part of the encryption process as a whole?
: If you don't know for sure that the enemy cannot crack your
: encryption, then precompression at least interferes with attacks
: based on statistical characteristics of the plaintext source
: language, which *might* reduce the chances of the enemy reading
: your message.
This appears to cover 100% of all cases.
: On the other hand, if you have justifiable confidence in your
: cryptosystem, precompression would be a waste of resources.
While this seems to cover pretty much 0% of them. How can you
/know/ that any confidence you have in your cryptosystem is justifiable?
You can't. You have to juggle probabilities.
Compression is not free. However it you're /already/ using compression -
and there are a number of reasons why this is sensible - using 1-1
compression /should/ be practically free - though there are probably not
enough 1-1 compressors around today for this to be true for many people
today.
:> 2) Are there special compression algorithms that are specifically
:> well-suited in combination with block cyphers? Is any of the
:> standard algorithms as good as the other?
: When the purpose of compression is to remove redundancy in order
: to suppress clues from the statistical characteristics of the
: plaintext source language, you simply want the highest degree of
: compression you can get (subject to your resource limitations).
...and /when/ is this the *only* point of compressing before encryption?
AFAICS, the answer to this is "never".
You're compressing in order to add strength, and frustrate the analyst -
*not* simply to remove redundancy present in the plaintext. Size simply
is not the only criteria which is relevant.
: D.Scott has been promoting "one-on-one" compression, for reasons
: you can read about in the sci.crypt archives of the past year.
: It seems to offer an advantage only if the cryptosystem already
: has some weaknesses that would normally be considered unacceptable.
Of course, if your entire system is already so strong that adding strength
makes no practical difference, you can forget about compression helping
with strength.
Who /knows/ that their entire system is this strong? In practice, very,
very few people do.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
$$$$$$$$$$$$$$$ Money lies at the root of all wealth $$$$$$$$$$$$$$$$$$
------------------------------
From: [EMAIL PROTECTED] (Sandy Harris)
Subject: Re: Basic Crypto Question 2
Date: 12 Feb 2000 17:57:07 GMT
[posted and mailed]
[EMAIL PROTECTED] spake thus:
>4. What about using PRNG's based on thermodynamics and random motion of
>molecules...or a theoretical model of some other natural random
>phenomena ....
the standard reference:
ftp://ftp.isi.edu/in-notes/rfc1750.txt
There is also some good stuff at counterpane.com, papers discussing
attacks on random generators and the design of their generator Yarrow.
>5. Has any vendor come up with a Physical Random Number generator box
>... white heat ..whatever, which sits on a network suppleying random
>numbers to client machines on a wan/lan?.. Need some kind of a tamoer
>proof secure box...
You don't want to do it over a network because that risks having some
network snoop learn your "random" numbers. Nothing the enemy can discover
is "random" in any useful sense, so you have to generate random numbers
on each machine and be cautious even there.
There are a fair number of hardware random number generator boards on
the market. Plans for homebrew ones appear on this newsgroup or on the
mailing lists perhaps once or twice a year. I'm sure a web search would
turn up several commercial and a few homebrew examples.
Intel have built a random number generator into their most recent chip
sets for motherboards. 810, 820, 840, ...
For software solutions, look at Counterpan's Yarrow and/or look at the
Linux /dev/random driver.
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: YACM - Yet Another Chaining Mode
Date: 12 Feb 2000 17:59:57 GMT
Yet Another Chaning Mode - CfBC
Probably mainly of interest to anybody collecting various non-defective
chaining modes. It 'hides' plaintext structure somewhat better than
CBC, while requiring more work on encryptionm and decryption.
Let:
P_n - n-th plaintext to be enciphered
C_n - n-th ciphertext
IV_n - n-th 'derivate' of the initalisation vector
E_k - encryption with key k
D_k - decryption with key k
Encryption:
IV_0=E_k(IV)
IV_n=E_k(IV_(n-1))
C_n=E_k(P_n ^ IV_n)
Decryption:
IV_0=E_k(IV)
IV_n=E_k(IV_(n-1))
P_n=D_k(C_n) ^ IV_n
Propeties:
DRAWBACK - divulges cyphertext at double rate.
1) hides plaintext structure well
2) blocks are chained, blocks cannot be inserted by a 3rd party in the middle
of the stream even if that party knows the key
3) in hardware can be implemented in parrallel, requiring about twice the
resources for no speed-down, in software runs at half the speed of an
interleaved implemetation
4) adds an additional tiny amount of security above just plaintext structure
hiding.
--
Sander
There is no love, no good, no happiness and no future -
these are all just illusions.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Basic Crypto Question 2
Date: Sat, 12 Feb 2000 19:08:31 +0100
[EMAIL PROTECTED] wrote:
>
> 1.Which are the Top 5 PRNG's for practical cryptosystems?
Unfortunately barely answerable with my humble knowledge. Besides,
the question is for me (personally) sort of like 'who are the top
5 beautiful girls of the world'.
> 2. Is there a Universal Tester to test the top 5 for Randomness?
There is a test known as Maurer's universal statistical test for
random bit generators. (But the sematics of 'universal' might not
unconditioanlly be identical with what you have in mind, I am afraid.)
The original paper by Prof. Maurer is in Journal of Cryptology 5
(1992), p.89-105.
> 3. Is it possible to test that a Crypto system is generating truely
> random keys...and the PRNG has not been chilled ??...Difficult task
> huh..with all the possible combination of keys..
It is rather difficult to define 'true randomness'. More precisely,
there is no unanimously accepted definition of that, as far as I
am aware. The ones that appear to be theoretically most attractive
unfortunately cannot be tested (verified) practically (on given
bit streams in practice). If you accept passing certain (do-able)
statistical tests as the 'definition' of 'true randomness', then
'by definition' you can test that. But then other people may not
accept what you call 'true random' to be true random in their view.
(Quite a time ago, debating about 'true randomness' has resulted
in a fairly long-durated thread in this group.)
> 4. What about using PRNG's based on thermodynamics and random motion of
> molecules...or a theoretical model of some other natural random
> phenomena ....
It is commonly believed/accepted that randomness from certain physical
phenomena provide good sources, from which random bit sequences of
superior quality, in particular unpredictability, can be obtained
(through some post-processing eventually to achieve improvements).
This viewpoint seems at least very reasonable.
> 5. Has any vendor come up with a Physical Random Number generator box
> ... white heat ..whatever, which sits on a network suppleying random
> numbers to client machines on a wan/lan?.. Need some kind of a tamoer
> proof secure box...
Yes, there are quite a lot of people doing business in that sector,
though I don't have their addresses at hand. Further, you can
download some amount of such random bits from an internet site.
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Feb 2000 17:49:21 GMT
Thomas Pornin <[EMAIL PROTECTED]> wrote:
: According to Tim Tyler <[EMAIL PROTECTED]>:
:> So, the question arises: do you *know* your entire system is not weak.
: If you want a simple answer: *yes*.
I'm very happy for you. I'll pray that your confidence is justified.
:> Other people should obviously concern themselves with compression,
:> given that very good compression can in principle make an analyst's
:> task well-nigh impossible.
: How do you know that any compression, even if it is very good, will
: annoy an analyst who, in your attack model, can defeat DFC with a
: 192-bit key ? [...]
Simple. Because any such attacker will need a halting criterion to be
able to perform his attack. "very good compression can in principle"
deprive the analyst of such halting criteria, under some circumstances.
: In my point of view, compression is not worth the effort; increasing the
: key size is a much cheaper and more efficient tactic (although I consider
: that beyond 96 bits, we jump from security to science-fiction).
Compression is part of the attempt to get the most from a given keyspace.
If keyspace came free of charge, we'd all be using systems like OTPs -
where the key is as long as the message. However, keyspace is *not*
generally considered to be free.
Also, IMO, for many algorithms, increasing the size of the keyspace is
only rather loosely connected with increasing the resulting security.
One strategy for increasing security is to use independent algorithms,
and independent keys in series. This is a crude way of increasing
security which works - in part - by attempting to avoid attacks on any
individual cypher.
This makes the keyspace increase dramatically. I feel there's a definite
role for very large keys, when employing such techniques.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
To iterate is human. To recurse is divine.
------------------------------
** 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
******************************
