Cryptography-Digest Digest #686, Volume #13 Wed, 14 Feb 01 02:13:01 EST
Contents:
Re: AES in PGPi? (Tom McCune)
Re: Minimal-space authentication algorithm (H. Peter Anvin)
Re: Hardware RNG - Where can I order one? ("Eric Braeden")
Re: Minimal-space authentication algorithm (Paul Rubin)
Re: Super strong crypto (wtshaw)
Re: Super strong crypto ("Joseph Ashwood")
Re: asking for stream cipher resource (Terry Ritter)
Re: Minimal-space authentication algorithm (H. Peter Anvin)
Re: Irreducible Polynomials over Z2 ("bubba")
Re: asking for stream cipher resource ("Trevor L. Jackson, III")
Key Exchange (George)
Building PGP 658 under Linux. ("Benjamin Scherrey")
National Security Nightmare? (JPeschel)
Re: Key Exchange ("Joseph Ashwood")
Re: Rnadom Numbers ("Douglas A. Gwyn")
Re: Hardware RNG - Where can I order one? ("Douglas A. Gwyn")
Re: Hardware RNG - Where can I order one? ("Douglas A. Gwyn")
Re: The Kingdom of God ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: AES in PGPi?
Date: Tue, 13 Feb 2001 22:11:10 GMT
In article <[EMAIL PROTECTED]>, Nick Battle <[EMAIL PROTECTED]> wrote:
>Sam Simpson wrote:
>> PGP 7.0.3 implements both AES (AKA Rijndael!) and Twofish.
>
>The documentation explains that Rijndael has several different key
>lengths that it can support (from 128 to 256), but it doesn't say what
>key length PGP uses when you choose the AES algorithm. Does anyone know
>what key length it uses?
PGP uses 256 bit for both AES and Twofish.
Tom McCune
My PGP Page & FAQ:
http://www.McCune.cc/PGP.htm
------------------------------
From: H. Peter Anvin <[EMAIL PROTECTED]>
Subject: Re: Minimal-space authentication algorithm
Date: 13 Feb 2001 14:18:11 -0800
Followup to: <[EMAIL PROTECTED]>
By author: Paul Rubin <[EMAIL PROTECTED]>
In newsgroup: sci.crypt
>
> What do you mean by "authentication algorithm"? What are you trying
> to authenticate? If it's (say) between a server and client, can you
> use a shared secret key between the client and the server? You want
> to minimize code space--do you also have to minimize RAM?
>
Okay, I should have been more explicit about this. I am working on a
network console open source project, and some people have been calling
for security since the intent is to provide the same kind of console
support that you could get on a direct-connected system.
Since part of the idea is that console access shall be granted as
early in the initialization process as possible, it is important that
the whole protocol stack, including any crypto, is minimal in size (on
the order of a few kilobytes.) RAM space is limited, but not as
limited as initialized space (code/data.)
It should be safe to assume the existence of a 32-bit processor, no
FPU. Speed does not need to be blazing.
The client system coming out of boot has no state; therefore it will
receive any initial state via BOOTP/DHCP. If the threat model allows
the adversary to snoop the network, this would rule out shared
secret. Note that I said "if"; I'm trying to figure out which threat
models can reasonably be defended against.
Once the client has initialized, there are three potential threats to
defend against; the following is the order of importance:
1. An adversary should not be able to issue a command to the client as
if it had come from the server. This is by far the most important
threat.
2. An adversary should not be able to snoop server->client traffic.
This is medium priority, becasue such traffic might contain
passwords.
3. An adversary should not be able to snoop client->server traffic.
This is low priority, because such traffic is unlikely to have
sensitive contents.
I suspect the main motivation for the people who want security is
because their network is untrusted; they are connecting their machines
to the open Internet and still want to be able to use network
consoles. I'm mostly trying to judge the cost of supporting various
options at this stage.
Many thanks for your information so far,
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
------------------------------
From: "Eric Braeden" <[EMAIL PROTECTED]>
Subject: Re: Hardware RNG - Where can I order one?
Date: Tue, 13 Feb 2001 17:35:56 -0500
Mike Rosing <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The Death wrote:
> >
> > Where can i buy a good hardware RNG that i can connect to my PC and use
to
> > generate secure random bits?
>
> http://www.protego.se/sg100_en.htm
>
> If you do a web search for "hardware random number" you'll get about
500,000 hits.
> Should be a few more than the one above!
>
> Patience, persistence, truth,
> Dr. mike
I use the SG100 on a regular basis. If you don't push it too fast it
really
does a good job. I've analyzed hundreds of Megs of data from mine and it
does a great job.
Eric
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Minimal-space authentication algorithm
Date: 13 Feb 2001 15:53:29 -0800
H. Peter Anvin <[EMAIL PROTECTED]> writes:
> Okay, I should have been more explicit about this. I am working on a
> network console open source project, and some people have been calling
> for security since the intent is to provide the same kind of console
> support that you could get on a direct-connected system.
>
> Since part of the idea is that console access shall be granted as
> early in the initialization process as possible, it is important that
> the whole protocol stack, including any crypto, is minimal in size (on
> the order of a few kilobytes.) RAM space is limited, but not as
> limited as initialized space (code/data.)
OK, but I'm still a little confused. What is a network console? In
particular, do you mean you want to authenticate by having a human
type a password on a keyboard? In that case you really should use a
protocol like SRP (http://srp.stanford.edu) to prevent dictionary
attacks against the password which you'd be vulnerable to if you used
a typical hashed-password protocol.
Anyway, a few kilobytes is a lot of code, or at least it was before
the current degenerate era. You should be able to implement most
reasonable algorithms in a few kilobytes if you're careful. As for
limited ram, in embedded processors that means 10-20 bytes are
available, not kilobytes. So it sounds like you have plenty of ram.
> It should be safe to assume the existence of a 32-bit processor, no
> FPU. Speed does not need to be blazing.
OK. You may also need to come up with some way of making random
numbers (entropy source) or of having some kind of persistent
updateable state for a PRNG at each end.
> The client system coming out of boot has no state; therefore it will
> receive any initial state via BOOTP/DHCP. If the threat model allows
> the adversary to snoop the network, this would rule out shared
> secret. Note that I said "if"; I'm trying to figure out which threat
> models can reasonably be defended against.
Wait a sec, if it has no state, does that mean it doesn't have any info
(like a public key) that can distinguish the server from an imposter?
If it can't, then you're hosed. If it can, why can't it share a secret?
> Once the client has initialized, there are three potential threats to
> defend against; the following is the order of importance:
Presumably once you're out of the boot code you can use a more complicated
protocol like IPSEC to secure the channel.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Super strong crypto
Date: Tue, 13 Feb 2001 18:04:30 -0600
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> <snip>
> > Wrong, you need fix-um-up modes, whiuch mean that they lack sufficient
> > independent strength as ciphers.
> <snip>
>
> Would you say a hammer lacks sufficient independent
> utility as a hammer because it has to be used in a
> certain way? (Start by picking it up at the right
> end, for instance.)
>
> JM
There is a wide range of sizes for hammers, one size does not fit all
uses. Likewise, an open-ended good generic algorithm should be fully
adaptable.
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 13 Feb 2001 16:11:04 -0800
"wtshaw" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <un2zCsUlAHA.319@cpmsnbbsa09>, "Joseph Ashwood"
> <[EMAIL PROTECTED]> wrote:
> ...
> > Let's see. I guess I'll begin with what strong cryptography is and is
not,
> > or rather whet we know and what we don't know. We don't know which
algorithm
> > is strongest, but we do know maximum values for it's strength.
>
> Joe, this means that you have no idea, pardon the pun. There is no upward
> limit as to strength, but there is to what you contemplate as feasible,
> which is pretty feeble compared to alternatives you seem to ignore.
Actually we do have absolute upper bounds on the strength of cryptographic
algorithms. It is known quite flatly that Rijndael has an absolute upper
bound of 128, 192, and 256-bits depending on how it is used. It is known
that DES has an absolute upper limit of 56-bits. These are absolutes and are
very well known. The attacks that are found against the algorithms decrease
that bound, but it makes it no less an absolute bound. It has been said many
tim by many different people, let me be the latest "Attacks never get worse"
> ....
> > Any of the 5 [AES}
> > of them should be strong enough for most things.
>
> Wrong, you need fix-um-up modes, whiuch mean that they lack sufficient
> independent strength as ciphers.
No it means that they deal only with the block cipher component, they do not
deal with the key mutation, the integrity, the signing, etc. They are a very
specific solution to a very specific problem. The debate regarding whether
or not that is the problem is quite seperate from the debate of the strength
of the ciphers themselves.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: asking for stream cipher resource
Date: Wed, 14 Feb 2001 00:32:19 GMT
On Tue, 13 Feb 2001 23:06:57 +0800, in
<96bikn$42h$[EMAIL PROTECTED]>, in sci.crypt "Eric" <[EMAIL PROTECTED]>
wrote:
>Could any one give me some web sites about stream cipher background,
>publications etc. ?
http://www.io.com/~ritter/LEARNING.HTM#StreamCiphers
http://www.io.com/~ritter/GLOSSARY.HTM#StreamCipher
http://www.io.com/~ritter/#LitSurvCiphers
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: H. Peter Anvin <[EMAIL PROTECTED]>
Subject: Re: Minimal-space authentication algorithm
Date: 13 Feb 2001 16:46:56 -0800
Followup to: <[EMAIL PROTECTED]>
By author: Paul Rubin <[EMAIL PROTECTED]>
In newsgroup: sci.crypt
>
> > The client system coming out of boot has no state; therefore it will
> > receive any initial state via BOOTP/DHCP. If the threat model allows
> > the adversary to snoop the network, this would rule out shared
> > secret. Note that I said "if"; I'm trying to figure out which threat
> > models can reasonably be defended against.
>
> Wait a sec, if it has no state, does that mean it doesn't have any info
> (like a public key) that can distinguish the server from an imposter?
> If it can't, then you're hosed. If it can, why can't it share a secret?
>
I guess I was making the assumption here that spoofing a DHCP response
was not feasible -- I don't know if this is a good assumption.
Obviously, if you can forge a DHCP response, all bets are off, and
there is nothing to be done about it. I think this is beyond the
scope of this project; some kind of "secure DHCP" certainly might be
possible, but that is another project entirely.
However, *observing* a DHCP transaction seems plausible for an
attacker, as it can be done with a regular network sniffer.
It could be that DHCP is so inherently insecure that there isn't much
of a point in trying to secure this.
> > Once the client has initialized, there are three potential threats to
> > defend against; the following is the order of importance:
>
> Presumably once you're out of the boot code you can use a more complicated
> protocol like IPSEC to secure the channel.
You could, but it would complicate things greatly, especially with the
transition.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: Irreducible Polynomials over Z2
Date: Wed, 14 Feb 2001 01:13:48 GMT
Try this:
http://sduplichan.home.att.net/primitive/primitivePolynomials.htm
There is a utility with C source code. I got a little carried away
optimizing, which makes it more difficult to read that it would be
otherwise. I considered making tables, but it would be easy to
use more space that my ISP gives me. To get a dense polynomial,
start a search with a pattern that is mostly dense, but has the least
significant few bits clear. The utility will increment the pattern and
test each for primitivity.
"Srdjan Sobajic" <[EMAIL PROTECTED]> wrote in message
news:96buom$9r4$[EMAIL PROTECTED]...
> Hello,
>
> I am looking for a reference which will have a table of irreducible
> polynomials over Z2.
> So far, most of the tables I have found are either for trinomials or
quintic
> polynomials.
>
> As I understand it, when implementing LFSR based encryption (say an
> alternating
> step generator) it is preferable to have dense connection polynomials
hence
> my question
> above. I have found algorithms (in the CRC HAC) which you can use to
> generate
> these polynomials, but if such a resource exists I would be grateful for
> some pointers.
>
> Thanks for your help,
>
> Srdjan Sobajic
>
>
>
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Reply-To: don't
Subject: Re: asking for stream cipher resource
Date: Wed, 14 Feb 2001 01:31:31 GMT
Anthony Stephen Szopa wrote:
> Eric wrote:
> >
> > Could any one give me some web sites about stream cipher background,
> > publications etc. ?
>
> http://www.ciphile.com
Now that's just a little too raw. Many people have told you that your
site is garbage. How dare you lead an innocent astray?
Such colossal effrontery is unacceptable. Prepare to be flamed every time
you show your keyboard in this newsgroup.
Twit.
------------------------------
From: George <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Key Exchange
Date: Tue, 13 Feb 2001 21:31:29 -0600
I'm working on a project where I need to have a client and a server
agree on a session key. What algorithm would be the MOST secure to use?
(Keeping in mind there is ONLY Alice and Bob and NO Trent). If
DiffieHelman were to be used, how often should Alice and Bob generate
new session keys? Any help is greatly appreciated. Thanks.
-George
[EMAIL PROTECTED]
------------------------------
From: "Benjamin Scherrey" <[EMAIL PROTECTED]>
Subject: Building PGP 658 under Linux.
Date: Tue, 13 Feb 2001 22:05:42 -0500
I'm trying to build the source for PGP 658 and am having difficulties
getting a complete build. I run the build script but it complains
(eventually) about not being able to find -lPGPui which I take to be some
file called libPHPui.[a|so] and probably the GUI part of the program
which is only available in Windows. So... why is the cmdline version
requiring a link to a GUI lib? Am I missing some option somewhere? I'd
appreciate any pointers from anyone successfully building this under
Linux. FWIW - I'm running x86 RedHat 6.2 using gcc-2.95.2.
thanx & later,
Ben Scherrey
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 14 Feb 2001 04:11:46 GMT
Subject: National Security Nightmare?
Hmmm... my bother-in-law at Ft Meade sent me this one.
http://cbsnews.com/now/story/0,1597,266857-412,00.shtml
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Key Exchange
Date: Tue, 13 Feb 2001 19:35:57 -0800
[sent to sci.crypt and via private e-mail]
Personally I'd suggest using ECC-MQV, it is very compact and there should be
little need to generate a new key during a reasonable length of time. For a
basic implementation I'd suggest Crypto++ (www.cryptopp.com) where it is
called ECMQVC. Alternately you could use DH-MQV same package slightly
different name. I recommend ECC over DH for a few reasons, the first is
size, ECC keys are significantly smaller than DH, the second and the reason
for the first is that the attacks against ECC are not as substantial, while
the underlying concept remains the same (it's still the DH problem).
Joe
"George" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm working on a project where I need to have a client and a server
> agree on a session key. What algorithm would be the MOST secure to use?
> (Keeping in mind there is ONLY Alice and Bob and NO Trent). If
> DiffieHelman were to be used, how often should Alice and Bob generate
> new session keys? Any help is greatly appreciated. Thanks.
>
> -George
> [EMAIL PROTECTED]
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Rnadom Numbers
Date: Wed, 14 Feb 2001 06:38:57 GMT
Mok-Kong Shen wrote:
> and that black box does not have other entropy input,
A "black box" practically by definition has some entropy
associated with it, which could be added to that present
in its input to create an output that is more entropic
than the input (all "entropy" measures being taken
relative to some fixed background state U).
As to the notion that there is some minimum amount of
computational work needed to exploit the information in
a given bit sequence, that is more or less what Chaitin's
algorithmic information theory is concerned with.
It is a lot easier to prove theorems about such things
when infinite sequences are considered than for finite
ones.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Hardware RNG - Where can I order one?
Date: Wed, 14 Feb 2001 06:41:09 GMT
The Death wrote:
> Where can i buy a good hardware RNG that i can connect to my PC
> and use to generate secure random bits?
Last time I wondered that I used a common Web search engine
and turned up half a dozen commercial products right away.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Hardware RNG - Where can I order one?
Date: Wed, 14 Feb 2001 06:42:38 GMT
George Weinberg wrote:
> I remember reading that Pentium III computers all have built in
> hardware RNGs, but there was a great deal of uncertainty as
> to whether they were any good.
Not on the processor itself, but in one of the supporting chips.
A search on Intel's Web site should turn up specific information.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.security,alt.2600
Subject: Re: The Kingdom of God
Date: Wed, 14 Feb 2001 06:48:37 GMT
JCA wrote:
> Why not a quote from the Old Norse mythology?
A locomotive with a Norwegian engineer and one being run by
a drunkard are on a collision course on the same track. But
don't worry, Norse is Norse and souse is souse and never the
trains shall meet.
------------------------------
** 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
******************************
