Cryptography-Digest Digest #640, Volume #10 Sat, 27 Nov 99 22:13:01 EST
Contents:
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: Thanksgiving and the invitation to distinction ("karl malbrain")
Re: How to generatekey pair for different users? (Nicky Boy)
Re: EncryptedChat V2 Dead ? ([EMAIL PROTECTED])
Re: EncryptedChat V2 Dead ? and dozecrypt ? ([EMAIL PROTECTED])
Re: Distribution of intelligence in the crypto field ("Douglas A. Gwyn")
Re: Noise Encryption ("Douglas A. Gwyn")
Re: Signals From Intelligent Space Aliens? Forget About It. ("Douglas A. Gwyn")
Re: How safe is Mobile Phone ? ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: Normal basis vs. Polynomial Basis (Christof Paar)
Re: Noise Encryption (John Savard)
Re: Noise Encryption (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: smartcard idea? ([EMAIL PROTECTED])
Re: smartcard idea? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Sat, 27 Nov 1999 23:05:16 GMT
"Trevor Jackson, III" wrote:
> Guy Macon wrote:
> > In article <81ogtv$upa$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St Denis)
>wrote:
> > >Ok, explain to me something that is truly random.
> > The time it takes for an individual atom of potassium-40
> > to decay to Argon-40.
> If you claimed a way to influence the decay process it would be possible to verify
>your
> claim. But if you claim that it is impossible to influence the decay process, it is
> impossible to prove that claim. Since your statement above presumes that the decay
> process cannot influenced, your statement cannot be verified or proven. So it rests
>on
> a belief rather than a scientific rationale.
That makes no sense whatever. The decay rate of an isotope is
determined by the nature of the isotope, and is a random variable.
The probability distribution is a simple exponentional function
of time, and derives from fundamental physical laws that involve
inherent randomness (not mere lack of information that could in
principle be acquired). These laws are part of the best-verified
theory of natural phenomena that we have. The randomness of the
decay is thus more certain than any other knowledge you may claim
to have.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Thanksgiving and the invitation to distinction
Date: Sat, 27 Nov 1999 15:07:36 -0800
<[EMAIL PROTECTED]> wrote in message news:81jfli$ksp$[EMAIL PROTECTED]...
>
>
> I am thinking of Churchill, and Chamberlain having dinner
> with a monster.
>
> There is wisdom in the sheathed sword.
>
> When that sword is withdrawn from its sheath, war and peace
> are distinguished and <B>both</B> become evils.
>
> Chamberlain sent optimism into the future expecting that it
> should reflect back into the present, and this is virtuous
> when our optimism in the future is indeed returned to us in
> the present, but sometimes such optimism is not returned to
> us, and we should respect that this can happen.
Their `optimism' was merely a prediction that the FASCISTS should liquidate
the COMMUNISTS if constrained to use their own devices. As a BOLSHEVIK,
STALIN was able to see through this DUPLICITY. Karl M
------------------------------
From: Nicky Boy <"nick_the_stronzo(nospam)"@hotmail.com>
Crossposted-To: comp.lang.java.security,microsoft.public.java.security
Subject: Re: How to generatekey pair for different users?
Date: Sat, 27 Nov 1999 23:09:22 GMT
Hiya Greg:
If you're expecting any sophisticated user to use key pairs that you create
for them, you're going to be disappointed!! <grin>
[EMAIL PROTECTED] wrote:
> Hi
>
> Does anyone know how to generate different private and public key pairs
> for different users?
>
> Thanks
>
> Greg
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: EncryptedChat V2 Dead ?
Date: Sat, 27 Nov 1999 23:03:47 GMT
Alexander,
It's up to you whether you use a program or not. Many encryption vendors
do not include source code - the choice is upto the user.
- Ben Stewart
NeuralAbyss Software
In article <81m1vd$ar9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> >
> > I am a software developer - my software may be
> > freeware but it's not GPLed - I wish to keep my
> > actual program source code "secret" - you can
> > download the RSA implementation via the Scramdisk
> > page - click on "delphi" and goto GInt/Triade
> > Systems from there...
> >
>
> Yes but the bugs are in your softs not in RSA implementation.
> Secret source code = a lot of bugs
>
> Users can trust secret implementations
> Sorry
>
> Regards,
>
> Alexander
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: EncryptedChat V2 Dead ? and dozecrypt ?
Date: Sat, 27 Nov 1999 23:02:46 GMT
Whoops! I mistyped the IV - it is 64 bits, but I only typed 10
characters - sorry!
- Ben Stewart
NeuralAbyss Software
In article <81m1cn$aeh$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> >
> > I do plan to include an IV in dozeCrypt III - and
> > I rely on dedicated users like yourself to help me
> > with my implementation. Currently I use an IV of
> > $7F55A304BC - but as you suggest it is constant.
> >
>
> ????
> You use a 40 bits IV ?? Blowfish uses 64 bits blocks, then IV should
be
> 64 bits long.
> Why a 40 bits IV ?
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Distribution of intelligence in the crypto field
Date: Sat, 27 Nov 1999 23:14:24 GMT
John Savard wrote:
> I'm sure they don't fit any pejorative description, but if one strips
> away the choice of wording, perhaps another post - by someone who had
> an acquaintance who placed in the top 5% of the Putnam, but whose
> acquaintance was not approached by the NSA - would make some sense.
> Before discreetly approaching such people, they might do a cursory
> background check, and avoid approaching people who, for example, have
> a history of certain types of political activity.
Why place so much credence in one posting? NSA is not in the
habit of hiring mathematicians right out of high school, but
when one does apply for a job, top performance in the Putnam
competition would be a positive factor.
Bright high school students *within reasonable distance of
NSA facilities* might be given summer internships, but the
full clearance process takes more than a whole summer, so it
would be a pre-recruitment ploy more than anything.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Noise Encryption
Date: Sat, 27 Nov 1999 23:20:48 GMT
"SCOTT19U.ZIP_GUY" wrote:
> ... unfortunately it is often the clueless newbie
> that makes the next big discovery.
Not usually. A fresh point of view can lead to discovery,
but cluelessness seldom does.
> The noble gas compounds.
The first noble gas compounds I ever heard of (halides)
were made by professional chemists, not by newbies.
Your main point seems to be merely that experts can be
mistaken. That's true (they're human), but that doesn't
mean novices are generally better than experts.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Sat, 27 Nov 1999 23:27:04 GMT
Lincoln Yeoh wrote:
> Oh. But that probably won't matter much. There are tons of other
> transmissions with junk in them too. ;).
Those other transmissions were aimed at beings who already had
a vast amount of knowledge of our culture(s) and language(s).
The one I was talking about was supposedly designed specifically
to communicate with beings that have no prior knowledge of us
nor our way of doing things (including language).
There is an article on this subject (in scanned-image bitmap
form) on NSA's FOIA Web page (look for the UFO documents; the
paper is by Callimahos, who should be familiar to readers of
this newsgroup). (I've converted it to a nice Word file with
the intent of making a PDF available on-line some day when I
get around to setting up my Web pages.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How safe is Mobile Phone ?
Date: Sat, 27 Nov 1999 23:33:48 GMT
Lincoln Yeoh wrote:
> Most analog cellular phones have no encryption. Trivial to eavesdrop
> with a scanner. Easy to clone too.
In fact, several of us commented on this during the (US) FCC
proceedings leading to the establishment of the US cell-phone
system. But it wasn't "three-letter agencies" that ignored
the problem, it was manufacturers greedy for quick bucks who
didn't want to delay while a proper engineering job was done.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Sat, 27 Nov 1999 23:36:34 GMT
Tom St Denis wrote:
> What is random about that? If you can model exactly every nick and
> nanny of the atom, then can't you recreate the decay?
No.
> I would classify that as 'hard to model' thus 'random'. But it's not
> universially random.
Yes, it is. Go study some physics.
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Normal basis vs. Polynomial Basis
Date: Sat, 27 Nov 1999 18:44:49 -0500
In many instances you might be better off with a polynomial basis
representation for HW implementation. They price you have to pay for NB
multipliers is quite hefty, even if you choose ONB multipliers (in fact, a
non-ONB multiplier is in most cases a complete disaster unless you use
pretty small fields). Unless you have an implementation that uses a lot of
squaring, PB is probably a choice that optimizes your implementation
better.
In this context it can also be relevant to bear in mind that PB squaring
can be done very efficiently (i.e., in one clock cycle with a moderate
number of gates but with a fair amount of routing) _if the field GF(2^m)
is fixed_ . This was described recently and independently in:
H. Wu: Low complexity bit-parallel finite field arithmetic using
polynomial basis. Workshop on Cryptographic Hardware and Embedded Systems
(CHES '99), August 12-13 1999, LNCS 1717, Springer-Verlag
and
C. Paar, P. Fleischmann, P. Soria Rodriguez: Fast Arithmetic for
Public-Key Algorithms in Galois Fields with Composite Exponents, IEEE
Transactions on Computers, October 1999, vol. 48, no. 10, pp. 1025-1034
The latter paper is on our web site (click the Recent Publications link).
Note that I am not claiming that efficient PB squaring is rocket science.
Hope that is of some help,
Christof
! WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES 2000) !
! WPI, August 17 & 18, 2000 !
! http://www.ece.wpi.edu/Research/crypt/ches !
***********************************************************************
Christof Paar, Assistant Professor
Cryptography and Information Security (CRIS) Group
ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon: (508) 831 5061 email: [EMAIL PROTECTED]
fax: (508) 831 5491 www: http://ee.wpi.edu/People/faculty/cxp.html
***********************************************************************
On Mon, 22 Nov 1999, Medical Electronics Lab wrote:
> Tom Pedersen wrote:
> >
> > If you need to implement a basis and the corresponding arithmetic functions
> > in hardware, which basis would you choose to be the most efficient and why?
> >
> > Addition is the same in the bases. Squaring is much faster in a normal
> > basis, but multiplication of elements can be cumbersome. But if you have a
> > Gaussian normal base of type I or II, would you then always prefer that over
> > a polynomial basis?
> >
> > Can anyone answer this or do anyone have any references to some sources on
> > the Internet to this problem?
> >
> > This is very relevant for encryption with elliptic curves.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Noise Encryption
Date: Sun, 28 Nov 1999 01:06:08 GMT
On 27 Nov 1999 07:18:18 PST, [EMAIL PROTECTED] (Guy Macon) wrote:
>Somewhere around the middle of the month, run every
>pseudorandom number generator that you can find.
Well, that will help improve the quality of physical random bits;
there's a program at
http://www.counterpane.com/
called Yarrow that illustrates the kind of techniques applicable to
this sort of thing.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Noise Encryption
Date: 27 Nov 1999 17:41:11 PST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo) wrote:
> This is known as a one time pad, and has been around for ages. For
>the moment I'll set aside comments on the randomness of the data, and
>physical security. A OTP is completely secure, in theory, as long as
>the pad is never reused and the data is truly random.
I thought that was true, but I decided to lurk here for several months
before posting and I see it called insecure a lot. I hadn't quite
tumbled on to the concept that what I was thinking of is the same as
a one time pad. I will do some more reading on it now. Thanks!
> One suggested change, allocate the disk so that each side has its
>own data to send with. If you only have no split you have a serious
>problem, let's say you send a 10k message to B and at the same time B
>sends a 1K message to you. You get the message and find that the 1K
>bytes you need have been burned off your disc so you can't decode the
>message. B has the same problem that you do. Even worse is that your
>attacker can combine both messages via XOR, the byte stream will
>cancel out leaving your attacker with 1K of text that is the XOR of
>the two plaintexts. While it might not be trivial to extract the two
>plain text streams from this, it is possible, and easily avoided.
Great idea. I hadn't thought of that.
>>Start with a hard disk that is all zeros.
>
> Not a requirement since you will be overwriting all the values
>anway. Nothing remaining on the disk from a previous run will be
>retained.
>
><snip of massive overkill>
>
> Use whatever makes you comfortable. You can take your end result
>and run the various statistical tests to see if the result is as
>random as you feel comfortable with depending on the security of your
>data.
> Having your computer connected to the internet exposes you to a
>serious security risk that you need not take. You coubl be exposed to
>a security leak via your OS, the internet, your various software
>components, or a deliberate trojan attack that could send your
>supposedly random stream directly to your attacker. You have to weigh
>this risk against the security you hope to achieve. Unless you run
>this process on a computer independent of the internet, I'd say you
>would be just as well off as using PGP to send the information to your
>friend.
I have zero intention of actually using encryption that I designed
myself! I make robots, not codes. I was asking to get clarification
on the various posts I see here about randomness being impossible and
one time pads being insecure. It seems like an attacker with infinite
computer resources could break PGP and read an intercepted message
(although there might no be enough matter in the universe to make
such a computer out of), but that my system could not be broken by
interception and decoding. In real life, PGP wins hands down. I am
just making a thought experiment to learn more about the supposed
insecurity and randomness issues.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 27 Nov 1999 17:52:58 PST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor Jackson, III) wrote:
>
>Guy Macon wrote:
>
>> In article <81ogtv$upa$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St Denis) wrote:
>> >
>> >In article <[EMAIL PROTECTED]>,
>> > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>> >> Tom St Denis wrote:
>> >> > Universially random should mean something which is random, and by NO
>> >> > MEANS at all predictable. However this cannot exist in nature.
>> >>
>> >> Who made you God?
>> >
>> >Ok, explain to me something that is truly random.
>> >
>>
>> The time it takes for an individual atom of potassium-40
>> to decay to Argon-40.
>
>If you claimed a way to influence the decay process it would be possible to verify
>your
>claim. But if you claim that it is impossible to influence the decay process, it is
>impossible to prove that claim. Since your statement above presumes that the decay
>process cannot influenced, your statement cannot be verified or proven. So it rests
>on
>a belief rather than a scientific rationale.
I *do* claim that there are methods to influence the decay process.
hitting it with enough neutrons or raise the temperature to solar
temeratures would do it. These would only change the half life,
not the essential randomness.
For a useful experiment, you would take two potassium-40 atoms, put them
in the same environment, and see which one decayes to Argon-40 first.
As for your argument concerning provability, it is a valid argument
that has the interesting property of applying to everything. You
can't even prove or verify that you exist, because your attempts to
offer proof presume that the evidence cannot be influenced or altered.
Logical, but not uesful.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 27 Nov 1999 17:56:28 PST
In article <81pn0e$n6g$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St Denis) wrote:
>> >Ok, explain to me something that is truly random.
>> >
>>
>> The time it takes for an individual atom of potassium-40
>> to decay to Argon-40.
>
>What is random about that? If you can model exactly every nick and
>nanny of the atom, then can't you recreate the decay?
Because, according to Heisenberg's uncertainty principle, you can't
model the atom.
>I would classify that as 'hard to model' thus 'random'. But it's not
>universially random.
Quantum mechanics says that it is impossible to model and impossible
to predict, except statisticaly.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: smartcard idea?
Date: Sun, 28 Nov 1999 02:07:03 GMT
99/10/03/1344228
In article <[EMAIL PROTECTED]>,
Shawn Willden <[EMAIL PROTECTED]> wrote:
>That much hardware isn't necessary, IMO. The
>PIN pad and display can be on
>the ATM rather than the card as long as
>(1)the card can authenticate the ATM and
>(2) the card can communicate the result of that authentication to the
>user.
>(2) can be accomplished by embedding an LED in the card which can be
turned on and off by the smart card microprocessor.
Your LED docking could be a LOT cleaner and more trouble free than
magnetic stripes or electrical contact pin connections.
I was thinking of a simple dog tag size device that would use a low
cost rolling one time pad system for authentication and encrypting data.
All of the functionality for getting new random data and renegotiating
keys after each transaction would be done from a secure server. You
could use the same card to authenticate and encrypt for any type of user
device connected to the server. The same plug in standard could be used
for ATM, cell phone, bank authorization, PC, etc...
If for example you were using the internet to make a transaction the
server would immediately record and lock the client IP address to your
account. Before the server would allow you to access your account for
your NEXT transaction you would be authorized using the previous
encrypted one time pad received and stored on your smart card at the end
of your LAST transaction.
In the unlikely event that a middle person somehow is able to crack the
encryption for a single transaction, the next time you authorize you
automatically rekey. If the intruder hasn't had time to access your
account first they won't have a current OTP and will be locked out.
If the bad guy had time to to counterfeit a tag (very difficult and
expensive) and access your account first, your OTP would be out of sync
with the server. You would be immediately notified of the intrusion and
your account could be be locked with the IP address of the intruders
last origin.
I am beginning to ramble about the obvious here, but with the cost of
Flash memory and processors coming down does anyone know who holds the
patent for this device?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: smartcard idea?
Date: Sun, 28 Nov 1999 02:38:21 GMT
In article <[EMAIL PROTECTED]>,
Shawn Willden <[EMAIL PROTECTED]> wrote:
> That much hardware isn't necessary, IMO. The PIN pad and display can
be on
> the ATM rather than the card as long as (1) the card can authenticate
the ATM
> and (2) the card can communicate the result of that authentication to
the user.
>
> (2) can be accomplished by embedding an LED in the card which can be
turned on and off by the smart card microprocessor.
Your LED docking would be cleaner and a LOT more trouble free than
magnetic stripes or electrical pin connections.
I was thinking of a simple multi-platform dog tag size plug in flash
device that would use a low cost rolling one time pad system for
authenticating and encrypting.
All of the functionality for getting new random data and renegotiating
keys would be done on a secure server. You could use the same smart
card to authenticate and encrypt on any device that could connect to the
server and supported the plug in standard. Plug in security for ATM,
cell phone, bank authorization, PC, etc...
If for example you were using a PC on the internet to make a transaction
the server would immediately record and lock the client IP address
attempting to access your account. Before the server would allow you to
access your account you would be required to authorize using the
previous one time pad encrypted and stored on your smart card from your
last transaction.
In the unlikely event that a thief is able to counterfeit your smart
card (very expensive and time consuming) your next authorization and
subsequent re-key will make the stolen OTP useless and lock out the
thief. This makes the window of opportunity for exploitation
considerably smaller than that of a credit card, and allows for instant
rekey.
I am beginning to ramble about the obvious here, but with the cost of
Flash memory and processors coming down someone must have thought of
this. Does anyone know who holds the patent for this type of
device?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
