Cryptography-Digest Digest #327, Volume #13 Thu, 14 Dec 00 12:13:00 EST
Contents:
Re: Embedded Linux System Vs Smart Card (Data)
Re: Embedded Linux System Vs Smart Card (Data)
Re: Software PRNG.. (Paul Crowley)
Re: YAPRNG (Paul Crowley)
Re: Embedded Linux System Vs Smart Card ("Richard Jewson")
Re: Software PRNG.. (Simon Johnson)
Something about RUK - Reservi Upseeri Koulu - the Reserve Officers School of Finland
---- the military (Markku J. Saarelainen)
When I drove back from New York to Miami in the end of October and it seemed that Al
Gore was winning Florida, I thought by myself "Onhan se jo nyt vittu jos George Bushin
veli ei voi taata Floridan voittoa" (Markku J. Saarelainen)
Re: Embedded Linux System Vs Smart Card (Data)
Re: Sr. Cryptographer/mathematician (Simon Johnson)
Re: Virtual memory security hole? (Mark Currie)
Re: Sr. Cryptographer/mathematician (Simon Johnson)
ethical considerations ... ("Peter Thorsteinson")
security by obscurity ... ("Peter Thorsteinson")
Re: Embedded Linux System Vs Smart Card ("Michael Schmidt")
Re: important programming languages ("Douglas A. Gwyn")
Re: binary vs. text w/ regard to digital signatures ("Douglas A. Gwyn")
Re: Unguessable sequence of unique integers? (John Myre)
Re: Unguessable sequence of unique integers? (John Myre)
Re: Sr. Cryptographer/mathematician (John Myre)
Re: Custom Encryption Algorithm (Marc)
----------------------------------------------------------------------------
From: Data <[EMAIL PROTECTED]>
Subject: Re: Embedded Linux System Vs Smart Card
Date: 14 Dec 2000 14:30:16 GMT
Michael Schmidt <[EMAIL PROTECTED]> wrote:
> Hi,
> I don't see any protected memory that is able to protect a private key
> against reading it (with standard computing equipment) from the outside.
Then, does the smart card has any mechanism to protect the data in its
memory?
-Data
> --
> ===================================================
> Michael Schmidt
> ---------------------------------------------------
> Institute for Data Communications Systems
> University of Siegen, Germany
> www.nue.et-inf.uni-siegen.de
> ---------------------------------------------------
> The 'Thin Client Security Homepage':
> www.nue.et-inf.uni-siegen.de/~schmidt/tcsecurity/
> ---------------------------------------------------
> http: www.nue.et-inf.uni-siegen.de/~schmidt
> e-mail: [EMAIL PROTECTED]
> phone: +49 271 740-2332 fax: +49 271 740-2536
> mobile: +49 173 3789349
> ---------------------------------------------------
> ### Siegen - The Arctic Rain Forest ###
> ===================================================
> "Data" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
> news:919cg7$1a5$[EMAIL PROTECTED]...
>>
>> Some people said that Embedded Linux System on prototyping board is as
>> secure as smart card. What do you think? Is it really tamper-resistant as
>> smart card?
>>
>> Example of Embedded Linux System:
>> http://developer.axis.com/hardware/devboard/
>>
>>
>>
>> -Data
------------------------------
From: Data <[EMAIL PROTECTED]>
Subject: Re: Embedded Linux System Vs Smart Card
Date: 14 Dec 2000 14:27:47 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <919cg7$1a5$[EMAIL PROTECTED]>,
> Data <[EMAIL PROTECTED]> wrote:
>>
>> Some people said that Embedded Linux System on prototyping board is as
>> secure as smart card. What do you think? Is it really tamper-
> resistant as
>> smart card?
>>
>> Example of Embedded Linux System:
>> http://developer.axis.com/hardware/devboard/
> Secure at doing what?
What I mean is if it is secure enough to protect the data from leaking
out as the smart card.
-Data
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Software PRNG..
Date: Thu, 14 Dec 2000 15:03:59 GMT
Tom St Denis wrote:
> > Try looking for Yarrow on www.counterpane.com.
>
> Yarrow is such a "wow nothing new". They use a cipher in counter
> encryption mode (i.e encrypt a binary counter) and they collect entropy
> and hash it into the key for the cipher. The only cool thing about
> Yarrow is that nobody proposed it 20 years ago.
Yarrow isn't meant as an exciting new innovation but as a solid piece of
engineering. Plus the use of two entropy pools, fast and slow, is as
far as I know innovative. The Yarrow paper explains very clearly their
reasons for publishing a description of the system.
In many ways, you remind me of the me of five years ago, and I'm now
paid to do cryptology and cryptanalysis so you might have a bright
future ahead of you. But I don't think I was ever as rude about the
work of the bright and thoughtful cryptographers that I look up to.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: YAPRNG
Date: Thu, 14 Dec 2000 15:06:11 GMT
Richard Heathfield wrote:
>
> Tim Tyler wrote:
> > In general piling RNGs on top of one another /is/ a road to greater
> > security - in much the same way that multiple encryption can offer
> > greater security.
>
> Thank you. I'll use a dozen, then. :-D
No, don't. If you want a PRNG you can trust to death, just use Rijndael
in counter mode. I see the temptation, but it's the Wrong Way.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: "Richard Jewson" <[EMAIL PROTECTED]>
Subject: Re: Embedded Linux System Vs Smart Card
Date: Thu, 14 Dec 2000 15:12:59 -0000
"Data" <[EMAIL PROTECTED]> wrote in message
news:91alho$k1r$[EMAIL PROTECTED]...
> Michael Schmidt <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > I don't see any protected memory that is able to protect a private key
> > against reading it (with standard computing equipment) from the outside.
>
> Then, does the smart card has any mechanism to protect the data in its
> memory?
>
Depends what smart card platform/product you use. Products such as
MULTOS/VOP or Cryptoflex
protect the card memory by firewalling it from other card based applications
and unauthorized
user access. Generally token storage implementations on smart cards never
allow private key information
to be exposed outside of the card.
Rich
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Software PRNG..
Date: Thu, 14 Dec 2000 15:39:18 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > Tom St Denis wrote:
> > > Well, I'd rather like to know "how", than get the code from
someone
> > > else. I mean, ofcourse it's cool to use something free, but
without
> > > completely understand it, then it's kind of impossible to truly
> > > trust it. Also, it would be difficult to know how secure my
algorithm
> > > is..
> >
> > I admire you. "I'd rather like to know "how"," the sign of a true
> > scientist!!!
>
> Well, how else could you improve yourself? Also, how could you come up
> with something better than the existing stuff today? =)
>
> > Well there are a lot of texts on it. I am not terribly well versed
in
> > the theory, just the implementations.
>
> Same here, but I'm trying hard to get "well versed", and I've found
out
> that the guys/gals in this NG are most kindly sharing their
experience.
> I'm grateful for that.
>
> > A LFSR is a Linear Feedback Shift Register and a LFG is a Lagged
> > Fibonacii generator (a special form of LFSR). LFSR style math has
been
> > used in CRC generators and various PRNGs.
>
> And these "algorithms" (?) are implementable in software? It sounds
like
> true hardware stuff. A computer can't possibly recreate everything
>that specific hardware devices can do.
They are both software and hardware algorithm. Though granted, LFSR's
run slower in software than hardware but they still work well.
> It seems also that if one should be able to create something truly
> random, one needs to "connect" with the analogue world in some way.
> The computers of today are, imho, too predictable. I have no proof
> of my statements, but it's some kind of feeling that I have.
The aim is not to make a real random sequence but to make a sequence of
statically random bits (that are determistic) from a key. Without
knowledge of the key, its should be impossible to predict the sequence.
> For instance when they (Sun? Sgi?) took a lavalamp and filmed it (?)
> and then used the information to create some random series. (The lava
> lamps are more or less random I've heard.) This is an example of using
> the "real" world to create randomness.
Yeah, there's lots of randomness out there. Radioactive decay is a nice
example....
> Also I read a post here, that a simple "RG" could be accomplished by
> sampling data from a microphone or similar. That is also
> a "connection"
> with the analogue world (although it becomes digital).
Recording straight sound is far from random, however atmospheric noise
peaks occur randomly. Generating bits from this is ok.
> The conclusion of this is that with today's computers, one needs to
> (in best case) take some random occurrance in the analogue world and
> use this to produce randomness in the digital world. Although with
> today's methods there are not really a 1-to-1 connection between the
> analogue world and the digital; the "data" has to be converted before
> entering the computer itself (via I/O). One far fetched (?) idea would
> to use the random analogue "data" to affect the hardware of the
digital
> world (not using A/D converters though). How this should be done, I've
> no idea...
Yes, for key generation and other such applications, you are correct.
But there is quite alot of entropy in the computer, its just harder to
exploit.
> BR/jh - nearly a non-believer of digital randomness.. (d'oh!)
>
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.security,alt.2600
Subject: Something about RUK - Reservi Upseeri Koulu - the Reserve Officers School of
Finland ---- the military
Date: Thu, 14 Dec 2000 15:35:48 GMT
In the society of Finland one of the main leadership schools is the
Reserve Officers Schools or RUK (Reservi Upseeri Koulu in Finnish) in
the military of Finland. Most, if not all, influencial Finnish
industrial and political leaders have gone through this school and
learned some leadership, intelligence and management skills. It also
serves as a network building environment for long-lasting people
networks in the society of Finland. My ex-brother (who was involved in
spying on and against me and my family ..) went to this school too. I
remember very clearly how one of his RUK friends then went to Orlando,
FL, U.S.A. after their military service (this was in 1980�s). It is
just too bad that he did not join the French Legion as he intended in
1980�s. People just as Jorma Ollila, Nokia, have also gone to this RUK
school. (Actually these Finnish reservists also have to go periodic
refreshments organized by the Finnish military.
I was put to the worst military unit in Finland in October, 1991,
although I had the good education, the international experience and had
the understanding similar to those people who were in the leadership of
Ahlstrom Corporation. My unit was full of handicaps and somehow
retarded. I personally had to act through my military experience and
pretend to fit in although I never did. I learned to behave in ways
they expected so that I would not be punished. I was never given the
opportunity to go to the Officer School etc. In many evenings I did go
alone to the library at the Officers School and learned about other
militaries and doctrines. I did this by myself and told nobody. I still
have the General Military Manual (with all rules and procedures of
Finland�s military) of Finland with me. In the end of my service I had
aminor nervous breakdown, which went unnoticed by anybody. I suffered
this alone as I had done so many years already. But I did earn one
medal during my military service: The Medal of the 70th anniversary of
the Soviet Union (quite amusingly) - and I still have this medal with
me.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.security,alt.2600
Subject: When I drove back from New York to Miami in the end of October and it seemed
that Al Gore was winning Florida, I thought by myself "Onhan se jo nyt vittu jos
George Bushin veli ei voi taata Floridan voittoa"
Date: Thu, 14 Dec 2000 15:42:10 GMT
When I drove back from New York to Miami in the end of October and it
seemed that Al Gore was winning Florida, I thought by myself "Onhan se
jo nyt vittu jos George Bushin veli ei voi taata Floridan voittoa" in
English "It is very bad if the brother of George Bush can not guarantee
the win in Florida". "Onhan se jo nyt vittu" is quite difficult to
translate.
But then he did ... well done ..
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Data <[EMAIL PROTECTED]>
Subject: Re: Embedded Linux System Vs Smart Card
Date: 14 Dec 2000 15:41:31 GMT
Richard Jewson <[EMAIL PROTECTED]> wrote:
> "Data" <[EMAIL PROTECTED]> wrote in message
> news:91alho$k1r$[EMAIL PROTECTED]...
>> Michael Schmidt <[EMAIL PROTECTED]> wrote:
>> > Hi,
>>
>> > I don't see any protected memory that is able to protect a private key
>> > against reading it (with standard computing equipment) from the outside.
>>
>> Then, does the smart card has any mechanism to protect the data in its
>> memory?
>>
> Depends what smart card platform/product you use. Products such as
> MULTOS/VOP or Cryptoflex
> protect the card memory by firewalling it from other card based applications
> and unauthorized
But how can you say firewall can effectively block all unauthorized access
to some data on smart card?
and how can you compare the effectiveness in securing the data in the
smart card and the Embedded Linux System board?
Can such board also have a firewall architecture to protect the data
on-board too?
-Data
> user access. Generally token storage implementations on smart cards never
> allow private key information
> to be exposed outside of the card.
> Rich
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Sr. Cryptographer/mathematician
Date: Thu, 14 Dec 2000 15:51:18 GMT
In article <91adko$2c9$[EMAIL PROTECTED]>,
Rick Booth <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > John Myre <[EMAIL PROTECTED]> wrote:
> >> Tom St Denis wrote:
> >> >
> >> > In article <1ZrZ5.287$[EMAIL PROTECTED]>,
> >> > "Matt Timmermans" <[EMAIL PROTECTED]> wrote:
> >>>> Your rather gritty usenet manner is sometimes entertaining, Tom,
but
> >>>> there are many reasons to be more civil.
> >>
> >>> "You're rather..." hehehehe... Just trying to have some fun.
> >> <snip>
> >>
> >> I'm not clear on something here. Do you seriously think
> >> that Matt made a spelling error, which you gleefully get
> >> to correct? Or, to be generous, perhaps you're attempting
> >> some sort of pun? (To be clear: Matt's post is correct.)
> >
> > He implied a state of being "to be"/"is" in which case "your" is not
> > correct. "You are better off..." is correct, or less
formally "You're
> > better off".
>
> No. "You're rather juvenile on usenet" would be correct, but Matt's
line
> was correct. A usenet manner is a possession, and this one belongs to
> you. "You are rather gritty usenet manner" is clearly nonsense.
>
> > Nanananana!
>
> Gritty is not the word I'd choose in this instance.
>
> - rfb
> --
> [EMAIL PROTECTED] http://www.ma.umist.ac.uk/rb/
> It is now quite lawful for a Catholic woman to avoid pregnancy by a
> resort to mathematics, though she is still forbidden to resort to
> physics and chemistry. -- H.L. Mencken
>
BUT then we could always ask ourselves, Do we care?
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
Subject: Re: Virtual memory security hole?
From: [EMAIL PROTECTED] (Mark Currie)
Date: 14 Dec 2000 16:06:33 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>"Paul Rubin" <[EMAIL PROTECTED]> wrote in message >
>> Why would your memory get written to disk in a crash? I mean it
>> might happen because of some bug, but your files might also get
>> broadcast over the network because of some bug.
>
>It is very common for OS's to dump a programs memory to the disk when the
>program commits an access violation such as accessing a NULL pointer. The
>dumped memory can be forwarded to the programmer for diagnoses. The UNIX
>term is 'core dump' the Windows NT term is "crash dump"
>
>> Suspending to disk is a function provided by OS extensions on some
>> notebooks, I think. So any encryption is done by the OS. But
>> I don't know of any OS's that actually encrypt when doing this.
>>
>> I have the not-especially-widely-shared opinion that stuff like
>> partition encryption should be done at the device driver level,
>> but that's just an engineering question, not a cryptographic one.
>
>The whole issue of accessing the swap file, and memory dumps raises a number
>of hard questions. Under what circumstances would your attacker be able to
>read the swap file, yet not be able to place a keyboard bug (Either hardware
>or software) on your system. A hole in your network security? A stolen
>laptop?
>
It's more of a general problem that sensitive data can end up on persistent
storage. Meaning that you can never trust the fact that there is no sensitive
data on your hard disk. If you have to upgrade/replace it you may need to
destroy it.
Mark
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Sr. Cryptographer/mathematician
Date: Thu, 14 Dec 2000 16:05:37 GMT
In article <915fi8$fve$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <2IfZ5.17746$[EMAIL PROTECTED]>,
> "Kevin" <[EMAIL PROTECTED]> wrote:
> > WE ARE LOOKING FOR EXPERT CRYPTOLOGISTS
> > in Ottawa, Canada
> >
> > You will have experience in 1 or more of these
> >
> > - Ciphers
> > - Cryptographic protocols
> > - Crytpographic hashing methods
>
> "Cryptographic" (spelling)
>
> > - Computaional complexity theory
>
> "Computational" also referred to "Combinatorics"
>
> > - Combinatorics
>
> ?hmm repeat?
>
> > - Number theory
> > - Numerical analysis
>
> These two are the same!
>
> > As part of the technology team you will participate in the design
and
> > analysis of our technology with regards to mathematical and/or
> cryptographic
> > techniques. You will aslo be expected to design new applications in
> the
> > above areas for incorporation into our secret-hiding, tamper proof
> software
> > encoding tools and to program key components to incorporate the
> designs into
> > our tool set.
>
> Tamper proof encoding tools? Shaw right.
>
> > Knowledge of Java, c++ Eiffel,Modula-3 or other object oriented
> language is
> > essential.
>
> Oooh buzzward compliancy... drool...
>
> Well I live in ottawa (Kanata specifically) you can contact me at
> tomstdenis@yahoo if you like.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
In defense of Tom.... he usually identifies the lamers quite easily. In
this case, he appears to be wrong. Many people have slammed his
descriptions of his various parts of maths (which admittedly i know
very little about) as so-called proof of his (near) Zero knowledge of
maths.
This is non-sensical. Simply because he doesn't know what name
something is called doesn't mean he cannot do math; it just means,
quite obviously, he doesn't known the name.
That's like calling John Lennon a poor musician because he couldn't
read music.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Peter Thorsteinson" <[EMAIL PROTECTED]>
Subject: ethical considerations ...
Date: Thu, 14 Dec 2000 16:25:59 GMT
Do there exist any ethical considerations regarding the maintenance of a
secret? What if such maintenance could potentially do harm to others?
Do there exist any ethical considerations regarding an attack on a secret?
What if the breach of the secret could potentially do harm to others?
------------------------------
From: "Peter Thorsteinson" <[EMAIL PROTECTED]>
Subject: security by obscurity ...
Date: Thu, 14 Dec 2000 16:35:29 GMT
It is often said that security by obscurity is not a valid approach.
However, I cannot see a fundamental difference between using an algorithm
that is difficult to guess, and a key that is difficult to guess (due to
large name space and uniform probability distribution). I agree that
parameterizing a general algorithm with a key is much more convenient that
establishing a new algorithm for each session, but I suspect that these two
approaches are not really different
Perhaps the most effective algorithm would be so general, that it could
perfectly simulate any arbitrary algorithm simply by passing it the
appropriate key. Wait a minute! That would be the operating system's program
loader, and the key would be that algorithm's executable code!
What do you all think?
------------------------------
From: "Michael Schmidt" <[EMAIL PROTECTED]>
Subject: Re: Embedded Linux System Vs Smart Card
Date: Thu, 14 Dec 2000 17:37:17 +0100
> > Depends what smart card platform/product you use. Products such as
> > MULTOS/VOP or Cryptoflex
> > protect the card memory by firewalling it from other card based
applications
> > and unauthorized
>
> But how can you say firewall can effectively block all unauthorized access
> to some data on smart card?
>
> and how can you compare the effectiveness in securing the data in the
> smart card and the Embedded Linux System board?
>
> Can such board also have a firewall architecture to protect the data
> on-board too?
>
It's not exactly the firewalling architecture that's relevant here. Modern
crypto smart cards simply do not allow reading of the files where private
keys for asymmetric crypto are stored, regardless whether internally or
externally. The only thing you can do with these private keys is
en-/decryption, i. e. you provide data to be en-/decrypted, and you get the
en-/decrypted results.
If you want to attack (i. e. read) the private keys stored inside, you have
to open the chip. Secret services are probably able to do this, an average
attacker isn't, since the chip self-destroys as soon as it encounters
tampering. That's a matter of > 100000 US$ (maybe tens of it).
A different story is attacks on the private key by not trying to read it,
but performing "chosen plaintext" attacks, timing analysis, power analysis
etc.
Even competing apps on the smart card are only able to read the
en-/decrypted results, but not the key itself. Isolation of these apps
against each other is where firewalling comes into play.
Michael
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: important programming languages
Date: Thu, 14 Dec 2000 15:49:24 GMT
Herman Rubin wrote:
> There are other situations where it matters. Some languages
> make some procedures almost impossible to even state. Some
> of the limitations are deliberately put in to "protect people
> for their own good".
> Let the programmer have access to the full power of the
> machine, often in ways which the language people cannot
> come close to understanding.
On a modern RISC processor, it requires an extremely high
degree of skill to implement an algorithm in assembly
language with a faster result than would result from using
the C compiler provided by the processor manufacturer.
It is certainly easier to maintain and port source code
that is written (with reasonable care) in C. Almost no
commercial applications are coded in assembler these days,
even if they only target Intel x86 processors; there is a
lot more to programming than simply getting a specific
machine to execute an algorithm one time, and the wider
economics of software development are not well served by
excessive use of assembly language.
There are a *few* circumstances in which a *small* portion
of an application will execute inefficiently in a higher-
level language, and if these bottlenecks are of sufficient
concern then it will justify coding *just the bottleneck
operations* in assembler in such a way that it can be
invoked from the rest of the application that is coded in
the HLL, but even so it still makes sense to maintain the
reference implementation in the HLL (for porting,
verification, and understanding in the maintenance cycle).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: binary vs. text w/ regard to digital signatures
Date: Thu, 14 Dec 2000 15:53:25 GMT
Benjamin Goldberg wrote:
> denis bider wrote:
> > EDDF uses canonical UTF-8 for all character data. Such a UTF-8 string
> > is equal to another UTF-8 string when the encodings are equal. No
> > dilemma.
> I have one minor nitpick here. Some characters, such as n with a ~ over
> it, have two graphically identical encodings -- as a single [combined]
> symbol, and as a letter (the n) followed by a non-spacing symbol (the
> ~). This applies to most of the letters of latin-1 which have the high
> bit set; they have their own encodings, and they can be encoded as the
> letter, followed by a non-spacing form of the overmark.
> Of course, this is a problem with UTF, than with EDDF, but it is there,
> and you shouldn't overlook it.
UTF-8 does *not* assign two encodings to tilde-n.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Unguessable sequence of unique integers?
Date: Thu, 14 Dec 2000 09:51:23 -0700
Brian Gladman wrote:
>
> "John Myre" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
<snip>
> > I took that to be implicit in Bryan's post.
>
> Maybe, John, but as you have just pointed out elsewhere, implicit
> assumptions are likely to put us on dangerous ground :-)
<snip>
Something about hoisting, and petards, here.
Thanks, I think...
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Unguessable sequence of unique integers?
Date: Thu, 14 Dec 2000 09:53:47 -0700
John Savard wrote:
<snip>
> Also, if just a counter is used - as he proposes - as input into the
> block cipher, then the problem is serious. Even if a linear
> congruential generator with a random starting point (and maximal
> period) is used, one knows that the plaintext blocks have alternating
> 0 and 1 bits in the LSB positions, so statistical attacks are possible
> at the least.
<snip>
Do you have a problem, then, with the proposal to
add "counter mode" as a new standard mode, as part
of the AES effort?
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Sr. Cryptographer/mathematician
Date: Thu, 14 Dec 2000 10:01:41 -0700
[EMAIL PROTECTED] wrote:
><snip>
> Likewise, it might be possible to have software that has all the
> information needed to run/break it, but have it be computationally
> infeasible to actually break the copy protection (or whatever your
> goal is). I've seen some schemes for this, but I've never seen one
> that looks really good.
<snip>
Yes, this is what Matt is posting about. Should we conclude
from experience that copy protection cannot work? Or is there
some analog of public key cryptography waiting to be discovered?
JM
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Custom Encryption Algorithm
Date: 14 Dec 2000 17:09:09 GMT
>Your standard answer to the people who post their cipher text is why
>would I waste my time decoding it.
Make a contest, with a $10,000 US price for the first to decode
your message.
This will a) make sure that you don't waste your/their time with
algorithms that you yourself don't see secure enough to protect
$10,000 US worth of secrets,
and b) motivate those who can crack the message to actually do it
instead of just explaining in theory how it can be cracked and
leave the rest as excercise for the reader.
I hope you are not too disappointed with the usenet. It's a
valuable resource of information, even when sometimes the people
don't "function" like desired..
------------------------------
** 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
******************************
