Cryptography-Digest Digest #649, Volume #10      Mon, 29 Nov 99 22:13:01 EST

Contents:
  Re: Peekboo Ideas? (jerome)
  Re: cryptography control? (Keith A Monahan)
  Re: A dangerous question (Johnny Bravo)
  Re: How safe is Mobile Phone ? (Jim Dunnett)
  Re: Random Noise Encryption Buffs (Look Here) (James Felling)
  Re: Noise Encryption (CoyoteRed)
  Re: kremlin encrypt any good?? which algorithm?? ("Ilya Kuryakin")
  Re: kremlin encrypt any good?? which algorithm?? (Johnny Bravo)
  Re: Cryptological discovery, rediscovery, or fantasy? (CoyoteRed)
  Re: PageSecure v2.0 - is it weak or strong ? ("Peter Lipp")
  Re: smartcard idea? ([EMAIL PROTECTED])
  Re: The Code Book (Derek Bell)
  Question About SHA-1 (dpwhite)
  Re: AES cyphers leak information like sieves ("Peter K. Boucher")
  Re: Use of two separate 40 bit encryption schemes (Johnny Bravo)
  Re: Distribution of intelligence in the crypto field ("Steven Alexander")
  Re: compact encryption in javascript (John Bailey)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (jerome)
Subject: Re: Peekboo Ideas?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 29 Nov 1999 20:15:49 GMT

On Mon, 29 Nov 1999 12:31:23 -0600, Medical Electronics Lab wrote:
>Tom St Denis wrote:
>>> I do have one question:  How do I implement human-readble message
>> signatures when things like email and usenet will reformat/addspaces?
>> Do I just discount spaces or something?  How does PGP do it?
>
>Stripping "white space" is perfectly ok to compute the hash of
>a message.  Remove tabs, spaces and new-lines.  That gives you
>pure text pretty much.  You may want to remove all control characters,
>in case there are form feeds added or whatever.  
>
>Warn people tho, in case spacing is important, they should fill
>lines with ........ to make sure things are in the right columns.

one of the aim of a signature is to be sure that the message hasn't
been altered. if you strip white space, any whitespace can be added
or removed without being detected by the signature.

i dont think it is a good solution but if you choose that, you have 
to be absolutly sure that the user is aware of this hole in the
signature process.

------------------------------

From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: cryptography control?
Date: 29 Nov 1999 20:35:21 GMT

Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: wtshaw wrote:
: >> The only true raw ingredients required in crypto are imagination and
: > insight; both are most difficult to outlaw.

: You don't outlaw them; instead, you control the educational system
: and make sure that imagination and insight are suppressed.

Hence Outcomes Based Education

Keith


------------------------------

From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: A dangerous question
Date: Mon, 29 Nov 1999 15:48:41 GMT

On Sun, 28 Nov 1999 21:55:55 -0800, Jim Nelson
<[EMAIL PROTECTED]> wrote:

>It's been a while since I read "Assassination Politics," but if my memory's
>right, the proposal was not an anonymous clearinghouse for hit man contracts. 
>The idea was a sort of dead pool, where people anonymously bet on the day and
>time such-and-such public official would be killed.  Everyone who guessed
>correctly would split the pot.
>
>The idea is that the assassin would place a "correct" guess -- he knows when
>he's going to act, presumably -- and collect the winnings.  Thus, no contract
>was made, no conspiracy planned, and so on. 

  How is this any different from putting out a contract on someone?
Anyone can play, and only the killer gets to collect.  The only
difference in the paper is that people have to put in money with each
guess to prevent massive random guessing.

> Double-blind anonymity ensures no one knows who's collecting or who bet. 

  This is where it breaks down of course.  Would you risk the rest of
your life in prison in return for a promised payoff by a person who
you don't know and can't find?

  Another problem is that the amount to be paid out would have to be
fixed before any bets were collected.  The author suggested that the
amount paid per guess be a fraction of the reward.  If some popular
figure who everyone hated came up on the block and the initial reward
was $1000 and the amount per guess was 1/1000 of that, you just put in
two years worth of reward from the very start (along with 1000 other
people).  The reward quickly reaches two million, someone will collect
and soon.  So everyone who put in the early bets gets to split the pot
with the killer.  The killer is going to be pissed when he puts in
$1000 and only gets $2000 back. :)

  Best Wishes,
    Johnny Bravo


------------------------------

From: amadeus @0SPAM.netcomuk.co.uk (Jim Dunnett)
Subject: Re: How safe is Mobile Phone ?
Date: Mon, 29 Nov 1999 20:55:01 GMT
Reply-To: Jim Dunnett

On 28 Nov 1999 23:06:26 GMT, [EMAIL PROTECTED] (Wim Lewis) wrote:

>In article <[EMAIL PROTECTED]>,
>Jim Dunnett <Jim Dunnett> wrote:
>>On Sat, 27 Nov 1999 00:45:14 +0800, "Hank" <[EMAIL PROTECTED]>
>>wrote:
>>>I am curious if the mobile phone system uses any data encryption mechanism.
>>
>>If you have a digital 'phone then I don't think you have anything to
>>worry about as I believe the entire process is encrypted over the 
>>radio path.
>
>This depends on the phone. There are lots of different digital cell phone
>protocols out there. The PCS phones you can get in the US aren't encrypted
>as far as I know, although the protocol supports it the hardware usually
>doesn't. GSM has encryption, though it is crackable with effort. I have
>no idea what is used in Taiwan (where the original poster presumably is).
>
>It is true that eavesdropping on a digital phone requires more effort than
>eavesdropping on an analog phone --- you'd need hardware built for the
>purpose, probably --- but it's not difficult enough that you can assume
>that no-one's going to do it.

I was thinking of the GSM system used here in Europe. It's encrypted, at
least in the UK.

Depends what security you want: if you only require immunity from casual
eavesdroppers, then you don't need encryption - the digitised signal 
itself will defeat all but the very determined and well-equipped
scanner user.

The GSM encryption can be broken, but not by the hobbyist and not
in real time.


------------------------------

From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Mon, 29 Nov 1999 14:54:36 -0600



Tim Tyler wrote:

> James Felling <[EMAIL PROTECTED]> wrote:
>
> [randomness from quantum events]
>
> : Given that the present quantum theories are indeed accurate -- and we have
> : no convincing evidence that they are not.  It is impossible to model an
> : atom so as to predict a decay.( you can make statistical assertions -like
> : on average there should have been 10 decay events by time t ), but you
> : cannot make definite predictions.  The uncertianty principle prevents
> : that.  This type of phenomena is fundamentally random.
>
> : True, if a paradigm shift occurs, and we come to understand these
> : phenomena on a more fundamental level, all bets are off, but until that
> : occurs(if ever it does), these events must be regarded as fundamentially
> : random.
>
> Even if one grants the thesis that quantum events may be considered
> to be random, that does not help terribly much with building a secure
> source of random numbers.
>
> Anything that amplifies quantum phenomena to a usable size is itself a
> macroscopic object.  If you ime radioactive decay emissions, you need a
> timing device.  You need a source whose characteristics are fixed, and
> so forth.
>
> Polarisation /looks/ promising - but you need to ensure nothing interacts
> with the particle between its creation and its measurement that can affect
> this in a systematic manner.  This means perfect vacuums, miles of lead
> shielding and worse.  Then there's bias in the detector itself - with
> what polariser can you be sure that exactly 50% of the particles get
> through?  It seems that the width of the slit cannot be made small enough
> for this to happen.  Consequently you're left with a biased source that
> you have to fix up.
>
> As far as I'm aware, the search for some direct physical source of
> completly secure random numbers is a fundamentally hopeless one - due
> to these sorts of effect.
>
> There remains the question of whether post-processing can patch things
> up by concentrating the resulting entropy.  Certain types of bias /can/
> - in principle - be completely removed by this type of processing.
>
> As far as I know, the answer to this question is also negative.
>
> If you know otherwise, feel free to present some sort of scheme you
> believe would be workable.

I am in agreement that the complete elimination of bias from a RNG is
impossible.  However, I feel that with present technology we can reduce the bias
to an arbitrarially low level.

>
> --
> __________
>  |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]
>
> Laugh and the whole world thinks you're an idiot.


------------------------------

From: CoyoteRed <[EMAIL PROTECTED]>
Subject: Re: Noise Encryption
Date: Mon, 29 Nov 1999 15:50:57 -0500
Reply-To: this news group unless otherwise instructed!

Guy Macon said...

>   I think that we are all familiar with the case of the
>   clueless newbie who thinks that he has discovered what
>   all of the experts have missed.  I see this a lot in my
>   field of expertise (developing real-time hardware and
>   software). The clueless newbie is almost always wrong,
>   and the new idea is almost always old.
>   
>   <sarcasm=ON> Given the above, I am sure that you will
>   all be just thrilled to learn that I, a clueless newbie
>   with no training in math or crypto, and without reading
>   any books on the subject, have invented a 100% perfect
>   non crackable method of sending messages over the
>   Internet!  And if you point out an obvious flaw I will
>   just patch it a bit and present it again, all the while
>   putting the burden of proof on you to prove it wrong,
>   and claiming victory if you ignore me!!!<sarcasm=OFF>
>   
>   Seriously, though, I just want to learn a bit more and
>   realize that my "new" ideas are probably just old ideas
>   that I have rediscovered.  That being said, here is my
>   idea for sending messages:

Don't worry, we are all newbies at one time or the other.

BTW, I'm still working on my system.  You'll see it here again when
more of the kinks are ironed out.

-- 
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com


------------------------------

Reply-To: "Ilya Kuryakin" <[EMAIL PROTECTED]>
From: "Ilya Kuryakin" <[EMAIL PROTECTED]>
Crossposted-To: alt.anonymous,alt.privacy,alt.security,comp.privacy,comp.security.misc
Subject: Re: kremlin encrypt any good?? which algorithm??
Date: Mon, 29 Nov 1999 21:06:15 GMT

Kremlin rools - use blowfish, rc4 or idea for best results

Ilya

--
PGP C-KT 6.0.2  I.D.: 0xFF2D3B33
ICQ: 44959127

rob <[EMAIL PROTECTED]> wrote in message
news:3Jr04.8783$[EMAIL PROTECTED]...
> is kremlin encrypt safe to use
>
> wich algorithm is the secure
>
> DES, NewDES, Blowfish, CAST, IDEA, RC4, Safer SK-128
>
>
>
> thanks
>
>



------------------------------

From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: alt.anonymous,alt.privacy,alt.security,comp.privacy,comp.security.misc
Subject: Re: kremlin encrypt any good?? which algorithm??
Date: Mon, 29 Nov 1999 16:13:36 GMT

On Mon, 29 Nov 1999 09:30:39 GMT, "rob" <[EMAIL PROTECTED]>
wrote:

>is kremlin encrypt safe to use

  According to recent posts I've seen here, in no way, shape or form
can it be considered secure.  They've screwed up the implementation of
the simplest algorithm it has; RC4.  If they can't get that right, how
can you trust them with anything else?

  Best Wishes,
    Johnny Bravo


------------------------------

From: CoyoteRed <[EMAIL PROTECTED]>
Subject: Re: Cryptological discovery, rediscovery, or fantasy?
Date: Mon, 29 Nov 1999 16:09:12 -0500
Reply-To: this news group unless otherwise instructed!

Dan Day said...

>   This sounds reasonably useless, until you realize that it can
>   be used as a very powerful lie detector. 

But lie detectors can be fooled and I'm sure there is a way to fool
this also.

-- 
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com


------------------------------

From: "Peter Lipp" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.security
Subject: Re: PageSecure v2.0 - is it weak or strong ?
Date: Mon, 29 Nov 1999 22:44:17 +0100

> Having looked at the decryption code, I am totally unable to determine
> whether it would indeed represent a challenge for experienced
cryptanalysts
> or not...
>
> Could someone check it out and do a quick evaluation ?
> See http://www.4cm.com/pagesecure/

What does it do? If it is secure, the author should tell us how it works
(didn't find anything on the pages directly and have no time downloading the
code, which doesn't contain code apparently). Technically, using password
based encryption, this should be doable in a safe way (decrypting the URL
using a password that is, disregarding that the URL gets then transmitted in
the clear most likely, unless you use SSL).

Peter



------------------------------

From: [EMAIL PROTECTED]
Subject: Re: smartcard idea?
Date: Mon, 29 Nov 1999 23:44:45 GMT

In article <81ujp0$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Guy Macon) wrote:
>
> It seems to me that in any situation where a one time pad gets out
> of sync the receiver could apply standard brute force techniques
> but instead of having to try all possible values of the one time
> pad [note] he would only have to try a sliding window that traverses
> the one time pad.  It seems like this would be pretty easy to do.
>
> Note: the brute force attacker, if he lives that long, will have a
> copy of the original message.  He will also have copies of every
> other possible message of that length, many of which would seem tp
> be valid, and no way to tell which one is the real one.
>

Despite the high MTBF an actual out of sync condition is probably more
likely to be caused by a hardware error e.g. client side flash memory
or server side hard drive crash then a weakness in the algorithm.

An attacker could perform a denial of service, pose as the server and
try to force a resync, but one of the advantages of using a smartcard is
that it is portable and you can quickly just take your encryption to
another device (location unknown to the attacker) and try connecting
from there.  Of course the security of this system is only as good as
the server security.


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: The Code Book
Date: 29 Nov 1999 23:52:26 -0000

Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: I spot-checked several topics in Singh's book, and found that he got many
: details wrong, indicating that he really isn't very familiar
: with the subject.

        He certainly got the Rossignol/nightingale/lockpick story back to
front - Kahn cited use of the term as a slang for lockpick centuries before
the Rossignols.

        Derek
-- 
Derek Bell  [EMAIL PROTECTED]                |   Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html|            usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc   |    - [EMAIL PROTECTED]

------------------------------

From: dpwhite <[EMAIL PROTECTED]>
Subject: Question About SHA-1
Date: Mon, 29 Nov 1999 16:04:04 -0800

I am considering the use (abuse, perhaps) of SHA-1 to generate unique
identifiers for java objects based upon their serialized state data. I
need to be able to quickly and easily discern one serialized object from
another based upon it's contents. There will be enough instance data to
allow adequate discrimination to occur. Since the SHA-1 digest mechanism
is part of the Java 1.2 distribution, it seems a likely possibility.

My question is about the possibilities of "collision" (the chance that 2
different inputs could produce the same SHA-1 result). In the write-ups
I have seen on SHA-1 there is mention of a low probability of such
collision but nowhere do I see a definition of "low". Obviously, with
the universe of possible, variable length inputs and a 160 bit result,
there must be some possibility of collision. We can accept this but
really would like some more accurate statement of what we can expect.

If anyone can assist in this definition, please email me at
[EMAIL PROTECTED] or [EMAIL PROTECTED]

Thanks in advance.

David

------------------------------

Date: Mon, 29 Nov 1999 17:22:33 -0700
From: "Peter K. Boucher" <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves

"Trevor Jackson, III" wrote:
[snip]
> Hmmm.  Are the participants in sci.crypt the kind of people that one sells to, or the
> kind that one reasons with?  The purposes and methods involved are quite distinct, as
> this thread illustrates.  Personally, I would very much like to believe the latter.

Posting insults laced with obscenity is not conducive to either
endeavor.

------------------------------

From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Use of two separate 40 bit encryption schemes
Date: Mon, 29 Nov 1999 19:32:16 GMT

On Mon, 29 Nov 1999 19:29:09 -0000, "tony.pattison"
<[EMAIL PROTECTED]> wrote:

>Johny,
>thanks for that. Alas the systems that I was thinking of, does not have
>access to realiable (new) encryption tecniques.
>
>I was trying to find a way around the problem, by using what I have at hand.
>
>Thanks
>Tony

  If you are stuck with DES use a huge number of encryptions.
1,048,576 encryptions of the message would add 20 bits. :)

  I'm curious, how are you stuck with DES?

  Best Wishes,
    Johnny Bravo

------------------------------

From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: Distribution of intelligence in the crypto field
Date: Mon, 29 Nov 1999 17:13:49 -0800

All the NSA has to do to stay ahead is hold onto their lead.  Until
recently, there wasn't any work in cryptography(in the US) unless you worked
for the NSA.  That it why they are ahead of commercial cryptography, they
have a solid 20 year lead in researching "modern"(computer) cryptography.

-steven




------------------------------

From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: compact encryption in javascript
Date: Tue, 30 Nov 1999 02:13:08 GMT

On Mon, 29 Nov 1999 14:33:22 +0100, "Eike Kock" <[EMAIL PROTECTED]>
wrote:

>Hi!
>
>I am looking for a compact public-key-based encryption algorithm I can
>easily implement using javascript in less than 10 lines of code. Anyone know
>of something like this.
>
>Thank you in advance,
>Eike
>
>
function ClearForm(form){    form.x.value = "";    form.y.value = "";
form.mod.value = "";    form.result.value = "";
      }function computeform(form) {     var r = 1, x, y,  m ;
        x = parseInt(form.x.value) ;
        y = parseInt(form.y.value) ;
        m = parseInt(form.mod.value)
        while(y > 0) {
                r = (r*x % m)*(y % 2) + (1 - y % 2)*r ;
                x = x * x % m ;
                y = Math.floor(y/2) ;
                                }
        form.result.value = r ;
        return;} 
Try it out at:
http://www.frontiernet.net/~jmb184/interests/cryptography/small_num_expont.html
John

------------------------------


** 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
******************************

Reply via email to