Cryptography-Digest Digest #79, Volume #13 Thu, 2 Nov 00 20:13:00 EST
Contents:
Re: End to end encryption in GSM ("Big Jase")
Re: Crypto Export Restrictions (CiPHER)
Re: Give it up? (CiPHER)
Re: ECC choice of field and basis (DJohn37050)
Re: RSA vs. Rabin (DJohn37050)
Re: Crypto Export Restrictions (David Schwartz)
Re: Detectable pattern in encoded stegaanographic images ([EMAIL PROTECTED])
Re: Is RSA provably secure under some conditions? (Roger Schlafly)
Re: ECC choice of field and basis (Greggy)
Re: ECC choice of field and basis (Greggy)
Re: ECC choice of field and basis (Greggy)
Re: Crypto Export Restrictions (Greggy)
Re: Is RSA provably secure under some conditions? (Roger Schlafly)
Re: Crypto Export Restrictions (Greggy)
Re: End to end encryption in GSM (Sundial Services)
Re: End to end encryption in GSM (David Wagner)
Re: Certicom's ECC Implementation (Greggy)
Re: is NIST just nuts? (Greggy)
Re: Hardware RNGs (Greggy)
Re: BENNY AND THE MTB? ("Matt Timmermans")
----------------------------------------------------------------------------
From: "Big Jase" <[EMAIL PROTECTED]>
Crossposted-To: alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: Thu, 2 Nov 2000 17:17:52 -0600
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:8ts99r$odn$[EMAIL PROTECTED]...
> Big Jase wrote:
> >How do you know any algorithm/mechanism/protocol is secure? You don't.
You
> >of all people should know this.
>
> Wrong. You tell that an algorithm (like 3DES) is likely to be secure
> because it has been scrutinized for many man-years by the world's best
> cryptographers.
You contradict yourself. You still don't know 3DES is secure do you? Likely
is not enough.
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 23:27:19 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Thank you for your intelligent input.
>
> Like we really need more of this.
*waggles fingers* OoooOOOooo! 'Intelligent input'!
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Thu, 02 Nov 2000 23:27:41 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Your guess is excellent. My PC has never had anything to do
> with media playing.
Okie dokie. That would explain it then.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: ECC choice of field and basis
Date: 02 Nov 2000 23:40:11 GMT
Any field is possible. One reason to use 2**p is every element is a bit
string, which maps nicely to computers. For 3**m or other prime, the mapping
is non-trivial. For simplicity sake, it was left out of P1363. The NIST
curves for example, are over binary or prime fields, not odd prime powers.
Also, the equations when using 3**m are different.
Regarding standards, I attend a few and each standards body has its own flavor
and purpose. ANSI X9 sets minimum security levels to be compliant, IEEE P1363
can be considered a toolbox and gives lots of useful info, but sets no keysize
requirements, ISO 15946 (kind of an ECC omnibus standard) also sets no key size
requirements. As I see it todaym here is a map
NIST curves < ANSI X9 < IEEE P1363 < ISO 15946. So if you use a NIST curve,
you can be compliant with all of them.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA vs. Rabin
Date: 02 Nov 2000 23:42:29 GMT
Rather, if you can take the square root, you can factor.
Don Johnson
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 16:00:11 -0800
8aked 1c3 wrote:
>
> > If course, the biggest problem is that no explanation is given of where
> > the randomness actually comes from. You can mix numbers to get random
> > numbers, but you need randomness in order to mix. Where does the initial
> > randomness come from? No clue.
> >
> > DS
>
> I know that Linux's "random" number generator, actually counts the seconds
> since the Apoch. (I forget the date of the Apoch)
>
> 8aked 1c3
What the hell are you talking about? Linux's random number generator is
based upon an entropy pool design developed by M. Matsumoto and Y.
Kurita. Its algorithmic principles are quite sound. WebMaster's RNG is
based upon it, and it's achieved independent certification by TST. The
primary source of raw entropy is clock skew between independent
oscillators as well as inherent randomness in processes that interact
with human beings.
DS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Detectable pattern in encoded stegaanographic images
Date: Fri, 03 Nov 2000 00:01:18 GMT
Correct me if I'm wrong, but you seem to be doing the following:
Take a file X with steganographically useful structure (ie the bmp)
add the steganographic component to X to create Y
(skip the transfer stuff)
When looking at Y versus X you can detect the difference?
This is a fairly obvious failure to understand stego. The purpose of
steganography is to hide a seperate message inside another message
(encrypted text inside a bmp in this case). If you have access to the
unaltered original, of course you can detect the presence of either
corruption or steganography. The point comes from the fact that your
assumed attacker does not have access to the cover message without the
stego (the original bmp in this case). Hope this helps.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Thu, 02 Nov 2000 16:18:24 -0800
Philip MacKenzie wrote:
> > You have proved it secure in some other universe that may not
> > have any relation to the real universe.
>
> I agree. It just _seems to_ have some relation to the
> real universe when talking about practical security.
>
> You may argue that there are better ways to get
> practical and secure cryptographic schemes, but
> at least with random oracle proofs, you won't have
> situations like with ISO 9796-1.
No, I think I'd even agree with that. With current knowledge, the
random oracle approach seems to be a reliable and practical way
of avoiding those problems. (Altho there is something to be said
for Cramer-Shoup, also.)
But look at the typical snake-oil claim. Someone will say his
system is provably secure because he uses a one-time pad.
After reading all the fine print, you discover that he is just
XORing with a pseudo-random number generator. Bogus, right?
But if your claims are legitimate, then he should be able to
legitimately claim that his scheme is "provably secure in the
pseudo-random number generator model of random numbers". The
only flaw is that the instantiation of the pseudo-random number
generator might be less than ideal. After a while, he gets
tired of saying so much, and just says "provably secure in the
random stream model", and argues that experts in the field
know what is meant by that statement. And when he has to
abbreviate to one or two words, he would just say "proof" or
"proved secure".
Most people was say: That's crap. He hasn't proved anything
about the PRNG that he actually uses, and it's bogus to claim
that his system is proved secure.
Now your results are much more substantial and interesting
than that, but the use of the word "proof" similarly rubs me
the wrong way.
I hate to pick on you so much, because you are just following a
trend, but my personal opinion is that it is a bad trend.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: ECC choice of field and basis
Date: Fri, 03 Nov 2000 00:12:13 GMT
In article <8tpumv$hd9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hello,
>
> Does anyone know where I could find the following basic information.
In
> ECC
>
> 1) What are the advantages and disadvantages of choosing GF(2^m) or
> GF(p) (and why not GF(p^m) in general)?
>
> 2) What are the advantages and disadvantages of choosing polynomial
> basis or optimal normal basis? Where can I find a good description of
> optimal nornmal basis?
I can answer the second question better than the first. I developed my
own ECC library for GF(2^m) - polynomial basis. The reason I chose
polynomial basis is that the math to code for optimal normal basis was
way over my head. Now that may not seem like a legitimate reason, but
when you think about it, how much more confidence does one have in a
cipher that is simple to understand?
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: ECC choice of field and basis
Date: Fri, 03 Nov 2000 00:15:13 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Regarding curves, check out the NIST recommended curves. These are
all
> recommended by NIST for governement use and give curves appropriate
to protect
> 80, 112, 128, 192 and 256 bit symmetric keys. www.nist.gov/encryption
>
> As you can see from the list, NIST (read NSA) thinks that both GF(p)
and
> GF(2**p) curves are OK.
Or one could say, NIST (read NSA) thinks that both GF(p) and GF(2**p)
curves are poor choices to secure data with, or they would never
recommend that others within the government use them.... :)
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: ECC choice of field and basis
Date: Fri, 03 Nov 2000 00:18:54 GMT
In article <8tshit$mar$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hello,
>
> Thank you all for your answers. Dr. Rosing, I have ordered a copy of
> your book (before your post actually!), but I haven't received it yet.
It's a good book to. Best book I ever read. ECC was like a dream. I
never thought I could write anything that could rival RSA, but within a
few months, I had my own ECC up and running. Completely different code
than found in the book, but the samples were absolutely necessary to
fill in the holes.
Another good book, Altered Evidence, by James Sanders. The only eye
witness to the crash wreckage of TWA flight 800 today that is telling
us what is in the hangar. Everyone else is keeping quiet.
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 00:23:34 GMT
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
>
> Anthony Stephen Szopa wrote:
>
> > Suspect?
> >
> > Anyone who would make such a claim and not support it is clearly a
> > nasty person.
>
> I'll let people judge for themselves, but the following
statements on
> your web site are not exactly encouraging:
> [... snip the talk ...]
Where's the source code? That is all I want. Show me the source code!
What? No source code? (sound of my sneakers walking away...)
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Thu, 02 Nov 2000 16:37:15 -0800
David Wagner wrote:
> > ... but what bugs me the most is
> >not just that you have an unverified hypothesis, but that you
> >have an unverifiable hypothesis.
>
> I agree that the distinction is important.
>
> But all proofs are relative to some idealized model (e.g., "the adversary
> can only interact with the system in the following ways"), and this too
> is an unverifiable hypothesis. There are no guarantees that your model
> is the right one, as witnessed by, e.g., timing and power attacks.
Those hypotheses are a lot more specific. If I know that I can get
security as long as my adversaries follow certain rules, that tells
me something specific. It may or may not be good enough for what I
want, but it is specific.
> So models are one type of unverifiable hypothesis, and the random oracle
> model is just one special case of this general phenomenom.
I say it is a very different kind of hypothesis. If there are timing
attacks, then I have some idea whether my system is vulnerable to
that. I have no idea whether SHA-1 is a random oracle approximation.
> I agree that the random oracle "assumption" should not be compared to
> the assumption that factoring is hard; but that doesn't mean that it is
> any better or worse than other models.
The factoring assumption may turn out to be worthless, if someone
finds a fast factoring algorithm. So in that sense we don't know
that the factoring assumption is any better than any other. But
at least the factoring assumption is something that is either true
or false in the traditional mathematical sense.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 00:25:39 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> [Bit of a massive crosspost, isn't it? alt.freespeech snipped - my
news
> server doesn't like it - I wonder why not? :-) ]
>
> David Schwartz wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> [snip]
> > > I then read the latest BXA info restricting the export of such
> > > encryption software.
> >
> > Have you even _read_ the current policy? It places
practically no
> > restrictions on crypto export to Austria, Australia, Belgium,
Canada,
> > Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary,
> > Ireland, Italy, Japan, Luxembor, Netherlands, New Zealand, Norway,
> > Poland, Portugal, Spain, Sweden, Switzerland, or the United
Kingdom. In
> > anby event, your algorithms look suspect, so it's just as well that
> > you're not peddling them as suitable for encryption.
>
> Is the US Government aware that its crypto export policy is a
> laughing-stock across the world?
What they are acutely aware of is that they are controlling their own
people (for who else can it enforce against) with the threat of jail.
Guess whose laughing?
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 02 Nov 2000 16:39:19 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Any cryptographic function is, in the final analysis, an obstacle.
There are many ways to get around it, including holding a gun to the
head of Alice or Bob, or wiring a trojan-horse into their machine or
software. Lots of ways to get around that cast-iron door without
bludgeoning one's way through it.
There could always be some hidden secret. There could also be a hidden
computer with massive parallelism to bring to bear upon the problem.
There could always be some "intrusion scenario" that could keep you
awake at night.
But eventually, you have secret messages to send and to receive, and you
need a system that is usable, by all parties, under real-world
conditions, that you have good reason to believe is "secure enough."
DES is such an algorithm. So is Rijndael or any of the AES finalists.
3DES is massive overkill for most purposes but it's there, too. You
select what is to you an acceptable mixture of speed vs. reliability vs.
security and then you -- use the darned thing.
If you become too fixated on "what if," you'll never send any messages
at all!
>Big Jase wrote:
>
> "David Wagner" <[EMAIL PROTECTED]> wrote in message
> news:8ts99r$odn$[EMAIL PROTECTED]...
> > Big Jase wrote:
> > >How do you know any algorithm/mechanism/protocol is secure? You don't.
> You
> > >of all people should know this.
> >
> > Wrong. You tell that an algorithm (like 3DES) is likely to be secure
> > because it has been scrutinized for many man-years by the world's best
> > cryptographers.
>
> You contradict yourself. You still don't know 3DES is secure do you? Likely
> is not enough.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: 3 Nov 2000 00:45:27 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Big Jase wrote:
>You contradict yourself. You still don't know 3DES is secure do you? Likely
>is not enough.
No, there's no contradiction here. Of course I can't prove that 3DES is
secure, but I do have good reason to believe that it is likely to be secure.
I told you about some of those reasons.
What I'm asking about the Sectra Tiger is there is any similar evidence
for its ciphers. What reason do we have to believe that they are secure?
Note: This is _not_ a rhetorical question; I truly am interested in the
answer, if there is one. Maybe there are good reasons! If so, I'd be
interested to hear about them. My interest is in learning, not in "winning"
some sort of debate match.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Certicom's ECC Implementation
Date: Fri, 03 Nov 2000 00:44:38 GMT
> Certicom states that their ECC implementation is somehow improved over
> others, due to some patented curves.
>
> Can anyone expand on this?
The patents are not on ECC calculations, but the implementations in
software (and I suppose in some cases on specific processors) to make
dramatic improvements on calculation speeds.
A search through the patents would make you realize why these ideas are
worth a patent. I don't like the fact that they are patents, but they
are good implementations and deserve patent protections.
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Fri, 03 Nov 2000 00:38:35 GMT
> > : [Twofish] wasn't the most secure or had the most security margain
> > : (Serpent wins that)
But it is good enough that we intend to use it commercially...
> > I think this is true if you assume that
> > additional rounds beyond the best
> > known attack result in more strength.
But wouldn't you agree that your assumption is that we know the best
known attack? While the NSA knows all we know, we know nothing that is
secret to them. So extra rounds are called for (assuming that you want
to hide your traffic from EVERYONE).
> Yeah but the idea is that known attacks are used as a metric in the
> absense of supreme enlightenment.
I have shared such a story about a man of God who received the password
for a UNIX account so that he could get on with completing his work and
go home to his family before it got to be real late. It literally
would have taken him many hours to track down the individual, but he
simply asked God for help, and immediately he had the answer.
Like the servant replying to the king who was warring against
Israel, "No one here is against thee, but the Prophet of Israel tells
the king of Israel what you say in your bedroom." When you have God on
your side, you will win.
I know. My God is faithful.
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Fri, 03 Nov 2000 00:46:51 GMT
Pent II has a new instruction that lets you sample the clock signal. I
have played with this, and under normal OS conditions, it seems to be
highly volatile in the lowest four bits (at least). This is what I
plan to use myself, for it beats anything else I have seen yet without
additional hardware.
> Why don't you just use soundcard input?
> pipe it into a file. It should be pretty darned random.
>
> Mark Carroll wrote:
>
> > Can anyone recommend any relatively cheap RNG cards for Intel boxes?
> > I'd like really good random numbers, so I figured that if they'd
> > satisfy you guys they'd satisfy anyone. (-: I'm particularly
> > interested in ones that generate numbers based on some physical
> > stochastic phenomenon and where I can easily get a driver for Linux
> > that gives me access to raw data coming from the card, even if it's
> > meant to be 'preprocessed' for good randomness. So, a card that
> > insists on doing lots of on-board digital processing itself after
the
> > 'random physics' step is of less interest.
> >
> > An obvious follow-up question regards any tips regarding easy-
reading
> > sources of tests for randomness. I'm happy to do the actual coding
> > myself, but I would like to be able to try to test the card under
> > different conditions and satisfy myself with regard to the
continuing
> > quality of its output.
> >
> > -- Mark
>
>
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Fri, 03 Nov 2000 01:05:39 GMT
"Brian Gladman" <[EMAIL PROTECTED]> wrote in message
news:dIhM5.5547$zO3.203267@stones...
> [...]
> I looked at your code quickly to find what you had done about end
treatment
> but I did not have time to look at your statistical model for the coder -
> what do you use?
The model is an unbounded length PPM model implemented with a sliding window
suffix tree. It is significantly modified from the standard unbounded PPM
model. It uses LOE a la PPMZ, and secondary escape estimation that really
isn't very good. These things just keep improving though, and beating bzip2
was my standard for the first release.
------------------------------
** 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
******************************
