Cryptography-Digest Digest #680, Volume #10 Sat, 4 Dec 99 10:13:01 EST
Contents:
Re: smartcard idea? ("Lyal Collins")
Re: Any negative comments about Peekboo free win95/98 message encryptor ("Lyal
Collins")
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Quantum Computers and Weather Forecasting (Rodney Blackall)
Re: What part of 'You need the key to know' don't you people get? (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Re: What part of 'You need the key to know' don't you people get? ("Rick Braddam")
Literature on secure systems engineering methodology--pointers needed (The Bug
Hunter)
Re: NSA should do a cryptoanalysis of AES ("Rick Braddam")
----------------------------------------------------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: smartcard idea?
Date: Sat, 4 Dec 1999 18:28:44 +1100
Batteries may not be a problem.
Some of the new polymer batteries (I think it's polymer) are used to form a
battery from the plastic carrier of the Smarctard.
Several audio smarctards are now on the market as a result - Elva, and
Telysys being 2.
Lyal
Shawn Willden wrote in message <[EMAIL PROTECTED]>...
>anonymous intentions wrote:
>
>> 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.
>
>I don't think there's anything inherently weak about contactless
>communications. Even with contact-based communications, we always assume
that
>an attacker can see and/or modify all of the messages. The problem with
>current-generation contactless cards is that they use weak crypto. The
reason
>they do is because the current induced by the RF field is too weak to power
a
>current-generation processor capable of performing DES operations in a
>sufficiently short time. With good cryptographic algorithms that are more
>efficient (AES) and more power-efficient processors contactless cards will
>become useful for applications that require relatively good security.
>
>> 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.
>
>Yes, a biometric device on the card itself is a very good idea, and there
are
>such card-embeddable devices available on the market. I don't know how
much
>they cost or what limitations they might have, but assuming there are no
>significant problems, I think a thumbprint reader on the card is ideal. It
>provides very easy to use, high-quality authentication without compromising
the
>user's privacy (by causing his or her fingerprint to be stored in a
database
>somewhere).
>
>Shawn.
>
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: Sat, 4 Dec 1999 18:30:17 +1100
Not only does SET suck, but your local machine does store the CC # in
recoverable format.
Lyal
Tony L. Svanstrom wrote in message
<[EMAIL PROTECTED]>...
>David A Molnar <[EMAIL PROTECTED]> wrote:
>
>> Yeah. This is why SET still seems interesting to me; the idea of doing
>> credit card transactions (if you _must_ do credit cards) without
>> storing the card # anywhere is a Good Idea. Too bad that a previous
>> thread here suggests that it's unworkable in practice...
>
>It really is useless, the idea is good, but SET sucks.
>
>
> /Tony
>--
> /\___/\ Who would you like to read your messages today? /\___/\
> \_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
> --oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
> DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
> ---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
> \O/ \O/ ©1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 04 Dec 1999 04:18:41 EST
In article <8294di$5a0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (r.e.s.) wrote:
>
>"Guy Macon" <[EMAIL PROTECTED]> wrote ...
>:
>: Maybe it's my background as an engineer, but if I was actually
>: implementing an OTP (instead of using PGP and just discussing
>: OTP as a learning experience), I would go full overkill on the
>: randomizer, XORing in everything from the number of microseconds
>: between keystrokes to a the digitized output of my local AM
>: station, the theory being that if any one of my "random" inputs
>: is true random, the OTP will be random. I would then pad my
>: plaintext to a standard length and XOR it with the OTP (which will
>: probably be on a CD-R). If (given the limitations that have been
>: pointed out) an OTP is unbreakable, how can it be strengthened?
>
>By "strengthen" I meant incorporate another stage of encipherment
>to produce a cipher (now no longer an OTP) that, in various attack
>scenarios, is more secure than an OTP alone. By "OTP alone" I mean
>direct transmission of XOR'd bits, granting "true" randomness of
>the key. (And "implementation" was intended to include modes of use.)
Let me rephrase that and see if I understand. You are saying to
take the OTP I described (which is unbreakable when used for
two way communication between trusted parties) then taking the
result and using it as the plaintext for an encryption system
that is in theory breakable but has other good qualities that
address various methods of beating OTP without trying to decode
an OTP encrypted message. I can't see any way that this would
increase or decrease the strength of the OTP against cryptoanalysis,
and it would address various noncryptoanalitical attacks.
So, would I use [PGP -> OTP], [OTP -> PGP], or [OTP -> PGP -> OTP]?
------------------------------
From: Rodney Blackall <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: Fri, 03 Dec 1999 17:31:35 +0000 (GMT)
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
[Snip]
> It is theoretically possible to obtain information about the missing
> components of the state of the Earth's atmosphere at a given time by
> the following technique: for each possible set of values for the state
> of the unobserved part of the Earth's atmosphere, run the equations
> backwards to obtain a long-term "prediction" of the weather on
> preceding days. That hypothetical state of the atmosphere which
> produces the longest-term accurate forecast in the reverse direction
> is the state most likely to be correct.
A process known in the UK Met. Office as 4DVAR and is a necessary
technique for incorporating asynoptic observations, e.g. satellite data.
It has been true for some years now that the UK's Unified Model produces
short-range forecasts that are more reliable than SOME of the
observations. This is because the forecasts are initialized by an analysis
based on the previous forecast ˜ which carries in it information from
earlier obs. This means that an isolated SHIP SYNOP from the Pacific will
affect the analyses and forecasts for hours or even days.
--
Rodney Blackall (retired meteorologist)
London, ENGLAND
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Dec 1999 11:21:53 GMT
James Felling <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
:> : 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. [...]
:>
:> : 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 tha[n] neighboring blocks.
:>
:> Indeed. This is my perception of his position also.
:>
:> While he's stated that he views the common chaining modes as weak, he's
:> *never* - to my knowledge - stated that they weaken the underlying block
:> cypher.
:>
:> Rather - as I understand it - his position is that they needlessly
:> expose the block cypher to direct attack, by a failure to distribute
:> information needed to decrypt the message over as wide as possible
:> an area.
:>
:> Obviously, such a failure to diffuse allows any attacks based on known
:> partial plaintexts to function. Or any attacks based on choosing
:> partial plaintexts for that matter.
:>
:> A proper use of diffusion would require *full* plaintexts, or *full*
:> chosen texts to be used before any such attack could succeed.
:>
:> As everyone knows, a partial plaintext is more common than a full one.
:>
:> This is likely to weaken the cypher /even/ if the only attack known on
:> the cypher is the use of brute-force.
: I am of the opinion that this does not weaken the cypher. [...]
I had hoped I had made it clear that I was comparing the various chaining
modes to diffusion. If this was less than clear, I apologise, and have
now (hopefully) rectified the matter.
It seems to me that diffusion prevents the same attacks as CFB chaining
does - and then some. Some people have made murmurings about attacks that
may be applied to systems that diffuse the information over the entire
file, which could not also be applied to a chaining mode. However,
while these murmurings remain murmurings, the only obvious downside
is the loss of error recovery in the cypher itself.
: The point that Mr. Scott makes that in CFB and CBC given the key, the IV
: will only hide 1 block GIVEN KNOWLEDGE OF THE KEY. SO the IV adds no
: direct security vs. decryption for later blocks.
This doesn't seem to be the spirit of his argument at all. Diffusion
doesn't even interfere with the decryption of the first few blocks.
Unkeyed diffusion of the type I am imagining is completely reversible.
An attacker with the key recovers even more information than he would with
a chaining mode.
The talk abot knowing the key was do demonstrate that the distribution of
the information in the file remained relatively fixed, and that no
large-scale diffusion had occurred.
: It does not WEAKEN the cypher however -- an n-bit key is still as
: resistant as it was before., it merey is not as strong as other potential
: feedback methods.
Yes, it was these I was /trying/ to compare with.
: Thus CBC and CFB are not substantially better than ECB given that your
: KEY HAS BEEN COMPRIMISED.
Nobody is suggesting here that the attacker has knowledge of the key.
Talk about knowing the key was to demonstrate the distribution of
information in the file, it was not intended to represent any type
of attack.
: An IV doesn't add to your resistance to a break vs. certian attacks,
: This still means that your algorithim is as strong as it always was --
: just that there is little in the way of added security fron a "secret" IV.
Well, the chaining mode helps defeat a variety of rather obvious
dictionary-based attacks. I'd say this helped significantly with
security.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Access denied - nah nah na nah nah.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Sat, 04 Dec 1999 03:38:27 -0800
Reply-To: [EMAIL PROTECTED]
Tim Tyler wrote:
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> [atomic randomness]
>
> : You have just discovered true randomness.
>
> Alas, even *if* this is genuinely random - which you will never
> demonstrate - nobody has developed a scheme for extracting this
> information onto a macroscopic scale without introducing bais of
> one type or another.
>
> Until such a scheme is demonstrated, "true atomic randomness" is
> of the same utility to a cryptographer as a "perfectly straight line"
> is to a student of geometry.
> --
> __________
> |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
>
> May all your hang-ups be drip-dry.
I think you have taken a misguided position and are struggling too much to
defend it.
I think that a very good true random demonstration would be to generate a
single photon and direct it through a tiny hole. Where it strikes a screen
on the other side of the hole will be unpredictable within the possible field
in which it may strike.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Dec 1999 11:52:37 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote [in reply to David Scott]:
: Why don't people use iron drop-bars to secure their front doors?
: The answer is, the locks they are already using are more secure
: than the rest of their house, e.g. windows, so beefing up security
: there doesn't really accomplish anything. Very few burglaries
: occur by the door lock being picked. Once the rest of the
: security system is made so good that the door lock becomes the
: weakest point, *then* it make sense to augment or change the door
: lock.
Iron bars are also expensive. If iron bars were free, and no more hassle
to lock and unlock than an ordinary door, I'm sure more people would use
them, even if the attack they are protecting against (a lockpicking
attack) are not known to be common.
As I see it, the situation in the two cases under discussion is that
yes, added information during compression is no worse than a known
plaintext, and yes, cyphers *should* be secure against known plaintext
attacks alone.
However, known plaintext attacks can be *combined* with other types of
attack. Say (for example) a weakness in the RNG that generates keys has
been discovered. Suddenly, 90% of the bits in the key are known with 90%
certainty. *Suddenly* a brute-force keysearch appears on the cards.
Suddenly, known-plaintext attacks can operate.
It would be very strange to claim that knowing the plaintext never
helps break a cypher.
There *many* are other ways of getting hold of partial keys, besides a bad
RNG. A malfunctioning office shredder, incomplete combistion, a partial
glance at a keyboard while a password is typed - I'm sure you can easily
imagine more.
So, having established the utility of these types of defence under some
circumstances, the main consideration in my mind is the cost.
One-on-one compression /should/ be free. Certainly more methods of making
1-1 compression schemes are currently being discovered - someone on
comp.compression has a 1-1 arithmetic coding scheme that looks like it
will work, for example. In a few years time, there will be enough of
these compressors available that using them will be a no-brainer.
Diffusion is a bit different. In the situations where it can be used,
there will commonly be some computational expense - especially on today's
serial machines with finite cache sizes. Eventually, diffusion will be so
cheap, that it will be virtually free. Today, some sort of cost-benefit
analysis will probably be needed to decide whether and how much to diffuse
in those circumstances where diffusion is appropriate.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Sometimes, a tagline is just a tagline.
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sat, 4 Dec 1999 06:19:42 -0600
James Felling <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Thus CBC and CFB are not substantially better than ECB given that your KEY HAS BEEN
> COMPRIMISED.
How sure can anyone be that complete key compromise is the only circumstance where CBC
and CFB are not substantially better than
ECB? How sure can we be that there are no attacks which are not publicly known?
> An IV doesn't add to your resistance to a break vs. certian attacks, This still
> means that your algorithim is as strong as it always was -- just that there is
> little in the way of added security fron a "secret" IV.
Doesn't it follow that there is little added security from the use of any of the
commonly used feedback methods?
BTW, the thread so far seems to have concentrated on CBC and CFB. I've seen little
mention of OFB. Does it have the same limited
scope of affect (2 blocks) as the other two, in spite of its resemblance to a stream
cipher? Or is there an effective attack which
makes OFB inadvisable?
> An all or nothing method is more secure vs. these forms of attack.However, the
> three letter methods do not weaken the underlying code, they merely fail to
> strengthen it.
If they fail to strengthen it, then they have failed to satisfy the objective for
using them, haven't they? If an all or nothing
method is more secure, is the difference in degree of security a significant amount?
I know, a lot of questions, and no answers. That's the nature of learning.
--
Rick
============================
Spam bait (With credit to E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: The Bug Hunter <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Literature on secure systems engineering methodology--pointers needed
Date: Sat, 04 Dec 1999 09:07:52 -0500
I've been searching the web for literature on methodology/process for
designing and developing secure systems. Maybe I was looking at the
wrong places, I couldn't find much.
I have my own process for engineering secure systems, but would like to
know what processes others use or advocate. Pointers anyone?
Many thanks in advance.
--The Bug Hunter
[Note: This is a re-post of my previous article, this time crossposted
to sci.crypt. I did find some material related to methodology of
engineering secure systems, but much less than I hoped. I was surprised
to find that even references to published works are difficult to find.]
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Sat, 4 Dec 1999 07:25:28 -0600
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> The chaining modes are not *meant* to evenly disperse PT
> information throughout a message; to do so would require the
> entire message to be available at one time, which is often not
> the case for real encrypted communication channels.
I've read this several times, on different threads. Each time I wonder *how* often it
is not the case that the entire message is
available at one time. The most important communications *for me* are e-mail,
newsgroup, chat, web pages, and form data. In each of
these it would seem to me that the entire message would be available before
transmission is started.
I know that there are streaming audio & video for computer users, tv, telephone, and
maybe even telegraph (for all I know), and that
the best type of encryption for me might not be the best type for those uses. The best
type for me is the type which gives me the
greatest assurance of privacy _in transmission_ since that is where I perceive the
greatest threat.
My hardware isn't designed with security in mind, my OS isn't either, and the programs
I use seem to be designed to thwart security.
Those are problems I can address, and *possibly* reduce, but not eliminate. My system
isn't continously available on the network for
attack, either. My IP address is dynamically assigned. I don't run any servers or
"remote control" services to allow my machine to
be operated from the network. I can compose messages off-line and limit my connection
time to an essential minimum. My connections
are at semi-random (new type of random?) times and durations. These things may not
help much, but they've got to be somewhat better
than staying connected full-time and running servers and services like remote shell
and remote login.
Let's eliminate commercial traffic from consideration. If it requires encryption it
won't use the same type I would anyway. Of the
remainder, what percentage of the traffic would be of the type I use? If we don't
consider commercial traffic (audio, video, tv,
etc,) would it be more often the case that the whole message *is* available before
transmission? With the way the network is
growing, what about next year? Or the one after that? What will the percentages be
then?
I don't mean to belittle applications where the complete message is not available
before transmission starts. I'm just pointing out
that they may not be applicable to the majority of users of the Internet. So I'm
asking: what type of data are the largest number of
users concerned with?
--
Rick
============================
Spam bait (With credit to E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
** 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
******************************
