Cryptography-Digest Digest #667, Volume #10 Thu, 2 Dec 99 18:13:01 EST
Contents:
Re: smartcard idea? ("anonymous intentions")
Re: NSA should do a cryptoanalysis of AES ("Trevor Jackson, III")
Re: Encrypting short blocks (Anton Stiglic)
Re: Use of two separate 40 bit encryption schemes (Eric Lee Green)
Re: Encrypting short blocks (Anton Stiglic)
Re: What part of 'You need the key to know' don't you people get? ("Trevor Jackson,
III")
Re: Encrypting short blocks ("Douglas A. Gwyn")
Re: What part of 'You need the key to know' don't you people get? ("Trevor Jackson,
III")
Re: Decyption proof cellphones in Europe? [x3] ("Trevor Jackson, III")
Re: more about the random number generator (Anton Stiglic)
Re: more about the random number generator (Anton Stiglic)
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
Re: Why Aren't Virtual Dice Adequate? ("Douglas A. Gwyn")
Re: NP-hard Problems (James Pate Williams, Jr.)
Re: NP-hard Problems (Anton Stiglic)
----------------------------------------------------------------------------
From: "anonymous intentions" <[EMAIL PROTECTED]>
Subject: Re: smartcard idea?
Date: Thu, 2 Dec 1999 14:28:15 -0600
Unless of course you create a rechargeable device in the HID proximity
card, but then you have the issue of spoofing via RF. Contactless isn't such
a great idea even if it is only transmitting a session hash. Contacts would
be better if they contained a pin on-board the card itself or on an
interpreter module on the card in which the PIN would never leave the card
or IM itself. Even better than that is a biometric thumbstamp that would
activate PIN access on the card interpreter.
kill4u at hushmail dot com
Shawn Willden <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
>
> > Your LED docking could be a LOT cleaner and more trouble free than
> > magnetic stripes or electrical contact pin connections.
>
> I wasn't suggesting the LED would be used for communication
> with the ATM,
> just with the user. Using it instead of electrical contacts
> would mean the
> card would have to contain its own power source (e.g. a
> battery) which isn't
> currently feasible, AFAIK.
>
> Shawn.
------------------------------
Date: Thu, 02 Dec 1999 17:32:58 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
> Anyone who thinks that NSA will get at information in future by
> breaking such algorithms (rather than their implementations) has not
> understood the closing of the cryptographic knowledge gap between the open
> and closed worlds.
How did you reach the conclusion that "the crypto gap" (shades of the 1950's
"missile gap") has closed? Why do you believe your supposed gap closing should
be obvious?
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Thu, 02 Dec 1999 17:33:48 -0500
"Douglas A. Gwyn" wrote:
> Markus Peuhkuri wrote:
> > Is there an encyprion algorithm that can be used for short
> > blocks (variable from ~10 to 24 bits) _and_ the result is same
> > length as original data.
>
> Yes, most binary-oriented stream ciphers have that property.
A stream cipher is not a block cipher.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Use of two separate 40 bit encryption schemes
Date: Thu, 02 Dec 1999 15:30:57 -0700
Shawn Willden wrote:
> double encryption to 41 bits. However, if you
> triple-encrypt your packets
> with 40-bit DES before transmitting them, you can get 80-bit
> strength (you
> can use either two or three 40-bit keys, but if you use two
> keys, make
> sure to alternate their usage).
One thing to note for us Amurricans is that the BXA would consider this to be
an 80-bit cipher, rather than multiple applications of a 40 bit cipher, and
would regulate it as such. Obviously I cannot say what a foreign government
would believe, but given the amount of incest at top levels, I suspect their
policies would be similar.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Thu, 02 Dec 1999 17:35:19 -0500
wtshaw wrote:
> In article <[EMAIL PROTECTED]>, Markus Peuhkuri
> <[EMAIL PROTECTED]> wrote:
>
> > Is there an encyprion algorithm that can be used for short
> > blocks (variable from ~10 to 24 bits) _and_ the result is same
> > length as original data. The key may be much larger (128, 256,
> > ...).
> >
> ....
> >
> > Could some existing algorithm be changed to work like that?
> >
> Sure thing, block length and key length have little relationship aside
> from what they do in an individual algorithm. When you change an
> algorithm, you have a different algorithm.
> Pick a block length, pick a usable keylength, design a good algorithm,
> case closed.
> --
Sure, just re-design everything. Analyse it, give it to others to check
it out, wait about two years to make sure it seems secure, no problem!
Anton
------------------------------
Date: Thu, 02 Dec 1999 17:38:50 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Douglas A. Gwyn wrote:
> Brian Chase wrote:
> > I think what I'm finding most disturbing, if not just outright disgusting,
> > is how quickly disregarded are Scott's challenges to the conventions of
> > the cryptology community. Sure he's an asshole, but as a community is it
> > not true that we don't conclusively know how secure the contemporary
> > algorithms are?
>
> Neither does D.Scott! The main problem with his arguments is that
> he asserts weaknesses in everybody's encryption schemes except his,
> but doesn't *demonstrate* the weaknesses. When he claims, for
> example, that CBC itself creates exploitable weaknesses, yet there
> happen to be solid mathematical papers demonstrating that CBC used
> with a *strong* block cipher is not substantially weaker than the
> block cipher by itself, it is incumbent on *him* to prove his claim,
> or at least to exhibit an error in the previous work that proved the
> opposite. That's not only standard professional practice, it's
> plain common sense. Since he doesn't make a convincing case,
> preferring to curse and challenge the integrity of anyone who
> disagrees with him, it is not surprising that he is being almost
> entirely ignored by the professional community.
No. You have egregiously misstated his position. AFAIK his position is that
CBC does not meaninfully strengthen a block cipher in comparison with methods
that diffuse information more widely that neighboring blocks.
I will admit that his position is somewhat slippery and lacking in convincing
demonstrations, but there is no need to distort the situation to make a case for
his claims lacking sufficient merit to be worth much attention.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Thu, 02 Dec 1999 22:39:33 GMT
Anton Stiglic wrote:
> "Douglas A. Gwyn" wrote:
> > Markus Peuhkuri wrote:
> > > Is there an encyprion algorithm that can be used for short
> > > blocks (variable from ~10 to 24 bits) _and_ the result is same
> > > length as original data.
> > Yes, most binary-oriented stream ciphers have that property.
> A stream cipher is not a block cipher.
And a cat is not a dog. So what? He didn't ask for a block cipher,
and why should he?
------------------------------
Date: Thu, 02 Dec 1999 17:43:07 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Johnny Bravo wrote:
> On Thu, 02 Dec 1999 15:10:00 GMT, [EMAIL PROTECTED]
> (SCOTT19U.ZIP_GUY) wrote:
>
> >Neither does D.Scott! The main problem with his arguments is that
> >he asserts weaknesses in everybody's encryption schemes except his,
> >but doesn't *demonstrate* the weaknesses.
>
> ><Begin Exact Quote>
> >Subject: Re: Which encryption brand is best?
> >Date: 1999/11/28
> >Author: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
> >
> >"Yes I think the AES candidates are weak."
> ><End Exact Qute>
>
> ><Begin Exact Quote>
> >Subject: Re: weak ciphers and their usage
> >Date: 1999/11/17
> >Author: SCOTT19U.ZIP_GUY
> >
> >"Here is something you can do with a crappy AES type of encryption
> >with your secret IV."
> ><End Exact Quote>
>
> No proof in this or any subsequent post was offered that the AES
> ciphers are weak or crappy. I'm quoting your words exactly as they
> are written, MR DS.
>
> >> Again I see the assholes misquote me. I never said that
> >>CBC makes a cipher weaker.
>
> You are a pathetic liar. You should write your delusions down so
> you can keep them straight when you post.
>
> ><Begin Exact Quote>
> >Subject: Re: weak ciphers and their usage
> >Date: 1999/11/17
> >Author: SCOTT19U.ZIP_GUY
> >
> >"I have been talking about the general weaknesses in all 3 letter
> >chaining mods."
> ><End Exact Quote>
>
> ><Begin Exact Quote>
> >Subject: Re: CFB mode with same initialization vector
> >Date: 1999/08/04
> >Author: SCOTT19U.ZIP_GUY
> >
> >"As I stated before all the blessed chaining modes are weak."
> ><End Exact Quote>
>
> ><Begin Exact Quote>
> >Subject: Re: Challenge to SCOTT19U.ZIP_GUY
> >Date: 1999/08/04
> >Author: SCOTT19U.ZIP_GUY
> >
> >"Yes these are my feelings that the chaining methods in use are purposely weak. "
> ><End Exact Quote>
>
> You claimed that ALL 3 letter chaining modes are weak. Not only do
> you claim they are weak, you claim were made weak on purpose, and you
> are the only one on the planet who knows the "truth." Yet you offer
> not even a hint of an attack against them, not even in theory. Why do
> you persist in denying you say this almost constantly.
Yes, he said all of that. But he was accused of claiming that chaining methods weaken
block ciphers. That acusation is false AFAIK.
BTW, his claim that chaining methods are weak is true if the standard of comparison is
that if full message diffusion. Since crypto lacks an objective standard of measure
one must constantly ask strong/weak compared to what? Of course a sensible writer
would _specify_ the relevant standard of comparioson, but I have failed to detect any
accusations that Mr. Scott is sensible.
>
>
> >Since all the 3 letter modes that you dumb people ever use really
> >add very little strength the the cipher.
>
> You are misquoting yourself now, more lies. You claimed that every
> single one of them makes the cipher weaker. And as for intelligence,
> proper spelling and grammar are not accidental constructions.
>
> >Most are to stupid to understand this fact.
>
> Most seem to see that this offers no help to the attacker, and since
> you can't prove otherwise and just resort to childish name calling why
> should we take you seriously. Act like a crying child, and get
> treated like one. You lie so much, we no longer care if you ever tell
> the truth. From your past history, we would be better off assuming
> everything you say is a lie unless you post it with evidence proving
> otherwise.
>
> > Of those smart enough to understand most don't seem to care.
>
> You have yet to demonstrate a practical attack that exploits this
> weakness. Saying it is weak is no the same as proving it is. Did you
> ever get around to showing your break for PGP 2.6.3 yet?
>
> ><Begin Exact Quote>
> >Subject: Re: AES tweaks
> >Date: 1999/05/27
> >Author: SCOTT19U.ZIP_GUY
> >
> >"One area that has greatly interested to me chainning and compression
> >PGP at least in 2.6.3 used inferior compression with what I call leaks
> >to the solution but this may have been a lack of experience."
> ><End Exact Quote>
>
> Since the solution is leaking, surely you are ready to publish your
> paper detailing your break of PGP 2.6.3. After all you have had 6
> months since you noticed the that the solution was just leaking out.
> When can we expect to see it, either online or published? Or is the
> lack of experience you mentioned your own?
>
> > In the three letter modes when some one does even a partical plain
> >text attack you can get the input output pairs to the underlying
> >blokc cipher. These may or may not be of use to the person breaking
> >the cipher.
>
> May or may not? Prove they are of use to a person breaking the
> cipher. May or may not, is not evidence of weakness.
>
> > I guess I just like to call a spade a spade big fucking deal.
> >you can call it a shovel.
>
> You like to call a spade a ball, and get all bent out of shape when
> people ask you what the hell are you talking about.
>
> Johnny Bravo
------------------------------
Date: Thu, 02 Dec 1999 17:44:30 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Eric Pinnell wrote:
> On Wed, 01 Dec 1999 19:54:36 +0100, Helmut Wabnig <[EMAIL PROTECTED]>
> wrote:
>
> >
> >Even if the Algorithms are known, how much effort would it take
> >to decrypt a transmission "on the fly".
> >Think this is rather impossible, I cannot imagine a way to do it.
> >Say, we could work on a recorded transmission, which in fact
> >is also difficult to make, how long will it take to bring up a result?
>
> This is easy. Simply feed all the digital information into a FIFO
> buffer. Suppose it takes your computer five seconds to start the
> decryption process. Simply buffer those five seconds beforehand.
> If you've got a massively parallel system like NSA has, it would be
> easy to decrypt in real time.
>
> >GSM transmissions of a certain GSM unit cannot be easily
> >filtered out of all the traffic on certain base station.
>
> All you need to do is know who you want to listen to, and you can
> monitor their transmissions and will. Even if they've got frequency
> hopping, the techincal means exist to read the traffic.
>
> >
> >Only the net providers can access individual beares,
> >or can disable encryption without notice.
>
> Or government agencies who know how the equipment works.
Note that this is the reason for "review" prior to export. One fundamental
aspect of suveillance is to know the capabilities of the opponents.
> Or who
> have tapepd into the communications network without the provider
> knowing.
>
> Eric Pinnell
>
> Qui Desiderat Pacem, Praeparet Bellum
> (Let Him Who Desire Peace, Prepare For War)
>
> Flavius Vegetius Renatus - 3rd Century BC
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Thu, 02 Dec 1999 17:41:08 -0500
Brian Chase wrote:
> In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
> >Tom St Denis wrote:
>
> >> Optimum compression would reduce the size
> >> of this 417792 bit file by 0 percent.
>
> >This comes directly from the entropy result.
>
> Naive question here. Let's say you had access to some "optimum
> compressor" which would take arbitrary data sets distill them into their
> most compact form. By definition, the resulting data must have no
> predictable redundancies, yes? Could you use optimally compressed data
> sets as sources for random numbers?
>
Your input would have to be random, so might as well just use the input
(you'd have more bits of randomness).
If you don't use random input, and I know about the compression algo
you use, I could just reverse the output (decompress) and look at the
results. If they don't look random, I know you are not using random inputs,
and might be able to predict futur outputs.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Thu, 02 Dec 1999 17:43:07 -0500
>
>
> > >Naive question here. Let's say you had access to some "optimum
> > >compressor" which would take arbitrary data sets distill them into their
> > >most compact form. By definition, the resulting data must have no
> > >predictable redundancies, yes? Could you use optimally compressed data
> > >sets as sources for random numbers?
>
> > In theory, yes. It would be roughly the same as a published
> > list of random numbers. No good for picking keys, but possibly
> > good for generating Sboxes, or anything else one could use
> > the Rand tables for.
> > Unfortunately, practice is a long way from theory. Even
>
> In practice the most compressed representation of a
> bit string is not computable.
>
>
Even if in practice you would have a perfect compresser, for the output
to be random, you would need the input to be random (if not I could
predict futur outputs, see my other post on this subject).
But if your input is already random, why that just use that!
Anton
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 02 Dec 1999 22:45:34 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Of those smart enough to understand most don't seem to care.
That should be a clue.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Thu, 02 Dec 1999 22:55:28 GMT
Guy Macon wrote:
> It seems that the attacker needs to also have to know that A sent
> the same message to B and C. Knowing B's plaintext and knowing
> that B and C got the same message resolves to knowing C's plaintext.
No, quite often there is reason for the intercepter to think that
the same message is being sent. Even if there is only a small
chance that it is so, that still may be enough to justify acting
on that basis. For example, if right, you may win the war, while
if wrong, you'll just cause the enemy to request a retransmission
of the garbled message he received (from you, although he doesn't
know that). The Zendian problem provides some practical
experience with exploiting identical PT to multiple recipients.
------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: NP-hard Problems
Date: Thu, 02 Dec 1999 23:05:28 GMT
What are some problems that are NP-hard but not NP-complete? I know
circuit-satisfiability is both NP-hard and NP-complete. In a textbook
I have r.e.-hard and r.e.-complete are defined where r.e. =
recursively enumerable. Are r.e.-hard and r.e.-complete the same as
NP-hard and NP-complete? MP (membership problem) and HP (halting
problem) are both r.e.-hard and r.e.-complete.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: NP-hard Problems
Date: Thu, 02 Dec 1999 18:09:27 -0500
"James Pate Williams, Jr." wrote:
> What are some problems that are NP-hard but not NP-complete? I know
> circuit-satisfiability is both NP-hard and NP-complete. In a textbook
> I have r.e.-hard and r.e.-complete are defined where r.e. =
> recursively enumerable. Are r.e.-hard and r.e.-complete the same as
> NP-hard and NP-complete? MP (membership problem) and HP (halting
> problem) are both r.e.-hard and r.e.-complete.
NP-complete problems are decisional problems (you answer yes or no,
does this element belong to a certain set, yes or no).
NP-Hard problems could be any sort of problems.
The big green book gives an example:
Given positive integers a_1, a_2, ..., a_n, and a positive integer s,
find the a_i that sum to s.
This is not an NP-complete problem since it's not a decisional problem.
The NP-complete problem (the decisional one) would be:
Given positive integers a_1, a_2, ..., a_n, is there (yes or no) a
subset
of these integers that sum to s.
Cheers!
Anton
------------------------------
** 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
******************************
