Cryptography-Digest Digest #45, Volume #10 Sat, 14 Aug 99 07:13:03 EDT
Contents:
Re: Future Cryptology ("Douglas A. Gwyn")
Re: About Algorithm M (Jerry Coffin)
Re: NIST AES FInalists are.... (Dave Knapp)
Re: Smart card generating RSA keys (DJohn37050)
Re: Q. a hash of a hash ... ("Roger Schlafly")
Re: About Algorithm M ([EMAIL PROTECTED])
Re: Future Cryptology (Patrick Juola)
Re: Future Cryptology (Anne & Lynn Wheeler)
Re: NIST AES FInalists are.... ("Thomas J. Boschloo")
Re: The Most Secure Symmetric Algorithm (not counting the one-time pad) ("Thomas J.
Boschloo")
Re: NIST AES FInalists are.... ("Thomas J. Boschloo")
Re: decryption verification methods ("Matthew Bennett")
Re: decryption verification methods ("Matthew Bennett")
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Future Cryptology
Date: Sat, 14 Aug 1999 04:50:26 GMT
David A Molnar wrote:
> This seems to be one of the reasons why cryptography correlates with
> computational complexity, by the way. If we can't prove a system
> secure, the next best thing is to show that breaking the system
> implies that P = NP.
You wouldn't be able to do that by breaking any specific instance of
a system; you'd have to find an attack against the entire class of a
parametric system such that the work factor went up only as a modest
function of the key size.
> Note that it may not be enough to show that breaking the system for
> some instance implies P = NP; we need it to be hard on the average
> (I think Doug Gwyn pointed this out as a deficiency of standard
> complexity theory in a separate thread) _AND_ not amenable to
> efficient approximation.
I think somebody else pointed that out, but I'll add that for many
applications, you need to know that *every* case is too hard.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: About Algorithm M
Date: Sat, 14 Aug 1999 00:22:36 -0600
In article <7p2bgk$n7i$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> > Knuth, V2 (page 32).
>
> Is that book still readily available? I might pick up a copy.
I really don't know, but I'd assume it is -- TTBOMK, there's no real
replacement for it. OTOH, I bought my copy around 15 years ago or so,
and haven't looked for it since, so I'm really not sure.
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sat, 14 Aug 1999 06:39:32 GMT
"Douglas A. Gwyn" wrote:
>
> "SCOTT19U.ZIP_GUY" wrote:
> > ... If they propose a system for AES it would be weak
> > enough so they could break it ...
>
> What has never been explained is the technical design that
> could allow such a cipher to be exploitable by the Agency
> but not by our enemies. You would think that would be an
> unacceptable risk.
It's actually quite easy to imagine such a system, as long as you are
completely ignorant about math and cryptology, as is Mr. Scott.
-- Dave
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Smart card generating RSA keys
Date: 14 Aug 1999 06:55:58 GMT
Or use a DL/EC system, where the private key is simply a random number.
Don Johnson
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Q. a hash of a hash ...
Date: Fri, 13 Aug 1999 11:21:59 -0700
Anton Stiglic wrote in message <[EMAIL PROTECTED]>...
>Say I have a hash algorithm H (I'm in fact using SHA_1),
>is using H(H(x)) as secure as using H(x), do the same properties
>for H stant for H of H ?
Sure, same properties. You may not be getting any extra
security, though. Given a hash h, it will be harder to find a x
with H(H(x)) = h than H(x) = h. But the bigger threat is that
of collisions, and any collision for H (ie, H(x) = H(y)) will also
be one for H of H (ie, H(H(x)) = H(H(y))).
------------------------------
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Subject: Re: About Algorithm M
Date: 14 Aug 1999 07:20:28 GMT
Reply-To: [EMAIL PROTECTED]
>> > Knuth, V2 (page 32).
http://www.bookpool.com/.x/ms65kk6gd6/sm/art_prg_set
'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'
Corne1 Huth - http://40th.com/
Bullet database engines/servers 3.1 Win32-WinCE-OS2-Linux+
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Future Cryptology
Date: 13 Aug 1999 15:54:01 -0400
In article <7p1q83$aqt$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <7ov8e9$f6i$[EMAIL PROTECTED]>,
>> So "neither" seems to me to be a very rational answer.
>
>You are not going to stop someone with more power then you, from
>reading your messages. Simple as that.
I disagree; in point of fact, that's the entire "work factor" argument;
not only does one need more power than me to read my messages, but
one needs to achieve a particular threshhold of additional power in
order to do so.
Reading messages and sending messages aren't inherently symmetric in
terms of difficulty, just as it's much harder to construct a building
than it is to destroy one. You and five of your friends are more powerful
than I (in our capacities as private citizens, &c. -- I'll explicitly
ignore the possibility that you're really a CIA spook or an archangel
in disguise); you (as a group) got more money, more time, more mobility
and so forth. Despite this sixfold increase in power, it wouldn't be
hard for me to make sure that you needed to spend much more than six times
the effort to read the message as I took to write it.
Similarly, the NSA has an effective effort of several million or several
billion times the amount of effort I can capable of deploying. This,
howeer, still establishes an upper bound of what the NSA *could* do; if
I have reason to believe that a particular technique requires more than
that effort, then (I believe) it's safe from the NSA.
>They can break into your
>house, tap your phone, kidnap your spouse etc etc etc... You should
>focus on making tampering or fraud hard (i.e can't be done remotely or
>via software) which will stop more people.
Why? *If* I can demonstrate a system effective against an NSA-level effort,
that will automatically be effective against similar-but-lower efforts.
Do I need that? Not necessarily... but I also don't need the extra 200MHz
of my PC's speed but it's cheaper to buy the fast cpu than to have a slower
machine custom-built.
>
>> So when did the NSA stop being "people"? If the NSA has the
>> capacity to break a system in such fashion, that's *NOT* to be
>> encouraged.
>
>The NSA is a buzzword (the word 'is' is technically correct since I am
>using it as a collective noun). Simple as that. Look at Dave Scott.
>He yaks on about the NSA all day long. Does he know anybody at the
>NSA?
Almost certainly not. But Mr. Scott's ignorance doesn't provide the
NSA with divine-level capacity.
The NSA *is* a buzzword -- specifially, it's usually shorthand for
passive cryptanalysis at the capacity of a major world government,
or for an effective upper bound for the capacity of passive cryptanalysis.
My question, then, is twofold : one, what *is* a reasonable estimate of
such an upper bound? I know it's not infinite...., and two, what would
be the cost of providing reliable security against such an upper bound?
Again, I know it's not infinite. For example, I am confident that RSA
with sufficiently large keys *will* delay cryptanalytic attack; although
I don't know what the fastest possible factoring algorithm is, I *strongly*
believe that it's slower than multiplication, and so there's a work-factor
gap.
*IF* -- and here the research question enters -- I can provide security
against an opponent with a budget-equivalent of a billion dollars for
$X, and I can provide security against an opponent with a budget-equivalent
of ten billion dollars for $Y, and so forth, is the additional security
worth the price? Answer : I dunno, it depends on your application. But
if $Y - $X is low enough (or even better, negative), probably. The
NSA has a finite budget... and so fits somewhere on that scale.
>What I would love to see is someone from the NSA respond to these
>messages and set some people straight.
Not going to happen; "Never Say Anything," remember? Besides, it's
to their advantage to sow fear and uncertainty about their capacities.
But it's not to yours to buy into the fear.
-kitten
------------------------------
Subject: Re: Future Cryptology
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 13 Aug 1999 20:13:21 GMT
[EMAIL PROTECTED] writes:
> In article <7ov8e9$f6i$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Patrick Juola) wrote:
> > I don't believe that it's at all a good question; I'm not sure a
> > cryptosystem exists that will protect me from the NSA but not
> > from "thieves and pesky hackers [sic]."
>
> That's not my point. My point was to stop focusing on stopping the NSA
> and focus on the real task at hand. I can't believe cryptograpers
> related to banking are thinking 'I wonder if the NSA can read these
> messages'. I bet they are thinking 'how much effort will it take for
> an attacker to forge transactions ...' or something like that.
>
as an aside the charter given the X9A10 working group for X9.59
protocol (for all account based transactions) was to preserve the
integrity of the financial infrastructure with just a digital
signature. much of current use of financial cryptography is for
message (transaction) authentication (independent of privacy
issues).
--
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sat, 14 Aug 1999 10:44:26 +0200
"Douglas A. Gwyn" wrote:
>
> "SCOTT19U.ZIP_GUY" wrote:
> > ... If they propose a system for AES it would be weak
> > enough so they could break it ...
>
> What has never been explained is the technical design that
> could allow such a cipher to be exploitable by the Agency
> but not by our enemies. You would think that would be an
> unacceptable risk.
This is not a problem. The Agency could just make the exploit just small
enough for them to crack with an enormous amount of resources, but not
for enemies because if would require to much computer time. Like a
weakness that reduces the keystrength of a 256 bit cypher to 70 bits,
but which would require a very specilized machine to crack efficiently.
If someone started manufacturing this kind of hardware in large amounts,
or allocated large computer resources towards it, they would know.
If the time came that enemies -might- be able to crack cyphertext
because of significant advances in computing power, they would just
release the weakness and get involved in the development of an new
encryption standard.
Thomas
--
AMD K7 Athlon 650 Mhz! <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: The Most Secure Symmetric Algorithm (not counting the one-time pad)
Date: Sat, 14 Aug 1999 11:22:43 +0200
"Douglas A. Gwyn" wrote:
>
> By the way, time travel is possible. I'm doing it right now.
> But it's unidirectional..
:-) But I do think traveling to the future is the only thing possible.
Traveling to the past would upset your past (like some atoms are
misplaced by you, causing an electrical storm in the future and striking
your teleportation boot). With small changes in your past, the future
will just look very very diffent and it gets worse the further back you
travel.
And compressing time would require traveling at near light speed. Moving
your computer at near light speed requires to much energy. I once
calculated that it would perhaps be possible to move a computer at 99.9%
of the speed of light at an enormous cost in energy (don't remember
precisely). And even that gains you only a factor 1000.
Thomas
--
AMD K7 Athlon 650 Mhz! <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sat, 14 Aug 1999 10:50:37 +0200
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> "Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote:
> > What I am worried about, is that some of the AES designers *ARE*
> members
> > of the NSA. That would be smart.
>
> Why? Then we would learn remotely new things from the NSA. That would
> not be smart. What if the cipher got broken and there was an NSA leak
> explaining why... That would cause a heap of !@#!.
You ask a very interesting question, I think. What would happen *if*
someone at the NSA leaked whatever information. It would be very easy to
do with anonymous remailers, or the yet to come freedom network
<www.zks.net>.
The whistle blower would however send cyphertext, and would probably be
very extensively monitored. This would give him away. It is ok for
people like you and me to use anonymous remailers, but probably not for
them. An other thing is that the NSA would know what was leaked, and who
knew about the information that was leaked. Then they could put people
on lie detectors or truth serums.
Now the question ?why? I think that having some AES designers secretly
work for you would be smart. The public might be able to learn new
things from -their- cypher, but they wouldn't know it was theirs and why
certain design decisions where made. Designers always have a certain
amount of freedom in their design, which they can fill by intuition. If
asked about certain design decisions, the collaborator could always come
up with some excuse like "it just seemed like a good thing to do" or "I
think the decision makes the algorithm more beautiful".
Thomas
--
AMD K7 Athlon 650 Mhz! <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "Matthew Bennett" <[EMAIL PROTECTED]>
Subject: Re: decryption verification methods
Date: Sat, 14 Aug 1999 11:29:41 +0100
Reply-To: "Matthew Bennett" <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
<snip>
> All three of them allow to detect, whether the correct key was used or
> not, but
> they don't allow to test the integrity of the whole file.
Indeed.
> > I'll be using Blowfish in CFB mode for the encryption, and SHA-1 as the
hash
> > function.
> > In particular is there an increased security risk if, say, someone knew
that
> > the first 8 bytes matched the next 8 bytes?
>
> It makes it simple for the attacker to find that a guessed key is the
> right
> one :)
Yes, this was a worry.. though the small (?) advantage to the hacker I hoped
would be outweighed by the potentially big advantage to the user.
> It may allow other attacks comparable to an attack using one known
> plaintext.
>
> > Does anyone know of a better verification method?
>
> For CBC there is a method known as CBCC: Add a block with the XOR of all
> plaintexts and encrypt this block as the last one. The attacker has to
> decrypt
> all blocks to get the plaintext of this last block while your methods
> make it
> neccessary to decrypt only few blocks. Every change in the ciphertext
> will change
> this last block so you get an integrity test for the whole file with
> only one
> additional XOR per block.
>
> You could use the same method for CFB.
>
> But maybe fast detection of an error is more important?
It was initially, but then I was going to use a separate method to test the
integrity of the whole file - which now seems unnecessary considering I can
do the two at the same time like you have suggested.
Thanks for your help :)
/\/\/\//
------------------------------
From: "Matthew Bennett" <[EMAIL PROTECTED]>
Subject: Re: decryption verification methods
Date: Sat, 14 Aug 1999 11:24:14 +0100
Reply-To: "Matthew Bennett" <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote in message
news:7p2ma2$u64$[EMAIL PROTECTED]...
> In article <7p1k97$6gs$[EMAIL PROTECTED]>,
> "Matthew Bennett" <[EMAIL PROTECTED]> wrote:
> > Other than simply encrypting a check phrase into the file and
> checking it
> > upon decryption, how would you rate these three other verification
> methods:
> >
> > 1) Write a random block of 8 bytes to a file followed by another
> duplicate 8
> > bytes, then encrypt. Upon decryption, check the first 8 bytes
> matches the
> > second 8 bytes.
>
> Oh great, give out known plaintext.
Thanks for confirming my suspicions that this method might be a security
risk.
> > 2) Hash the first 32 bytes of the file, encrypt the whole file, store
> the
> > original hash value at the beginning. Upon decryption, hash the same
> 32
> > bytes and check the number produced matches the original value.
>
> Um why not hash the entire file? What if I copy the first 32 bytes and
> forge the rest? ('Dear Sir, I would be pleased to ') there 32 or so
> bytes ... no real message as of yet.
I was looking for a simple "correct pass phrase" check, not a file integrety
check - so only a small portion of the file would need to be considered, and
would also be quicker.
> > 3) Like method 1, but sandwich a small part of the data file between
> the two
> > 8-byte blocks.
> >
> > I'll be using Blowfish in CFB mode for the encryption, and SHA-1 as
> the hash
> > function.
> > In particular is there an increased security risk if, say, someone
> knew that
> > the first 8 bytes matched the next 8 bytes? Does anyone know of a
> better
> > verification method?
>
> I would suggest learning more about crypto protocals before trying to
> implement one yourself.
I think you might have misunderstood - I have not "made up" any of these
myself, they have all been taken from quite lengthy www searchs. I had
doubts about their suitability myself, which is why I posted them here. In
doing so, I thought this was a suitable newsgroup in order to learn a bit
more about them.
> A standard method would be to hash the message, encrypt the hash and
> append it. This gives out no known plaintext and ensures the integrity
> of the entire file.
Perhaps combining a pass phrase verification and file entegrity check might
be better afterall as you suggest, though I was originally going to use two
separate methods so as to be able to distingush between the two and give an
appropriate warning.
> Another concern, why are you using CFB for file encryption? You should
> use CBC.
I wasn't aware CFB was considered an unsuitable method, as I understood both
implementations had good and bad points. The source code I'm using for
Blowfish only supports ECB and CFB itself, and I didn't see the need to
specially get hold of CBC code. Still, what reasons would you suggest for
especially using CBC and not CFB?
/\/\/\//
------------------------------
** 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
******************************
