Cryptography-Digest Digest #902, Volume #9 Sat, 17 Jul 99 14:13:03 EDT
Contents:
Re: obliterating written passwords (Keith A Monahan)
Re: obliterating written passwords (Nicol So)
Re: How Big is a Byte? (was: New Encryption Product!) (Natarajan Krishnaswami)
Re: A few qustions on encryption (Keith A Monahan)
Re: NBE: Not crackable by brute force key search (James Andrews)
Deal for cracking ! ("DoktorWHO")
NBE crap and snake oil (Keith A Monahan)
Re: Not crackable by brute force key search ("User")
Re: Quantum Computers (Bodo Moeller)
Re: randomness of powerball, was something about one time pads (fungus)
Re: How Big is a Byte? (was: New Encryption Product!) ("donald tees")
Re: How Big is a Byte? (was: New Encryption Product!) (Peter Seebach)
pure perl solution for Blowfish, DES or IDEA? (Rainer Hillebrand)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: obliterating written passwords
Date: 17 Jul 1999 12:44:15 GMT
fungus ([EMAIL PROTECTED]) wrote:
: "Douglas A. Gwyn" wrote:
: >
: > [EMAIL PROTECTED] wrote:
: > > Just burn it....
: >
: > And stir up the ashes.
: And eat them.
hahahah
: --
: <\___/>
: / O O \
: \_____/ FTB.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: obliterating written passwords
Date: Sat, 17 Jul 1999 09:52:22 -0400
wtshaw wrote:
>
> Try a chalk board, or lipstick on a mirror, writing implement borrowed I
> hope. Or, use a fine shredder.
Variation on the "lipstick on a mirror" idea: a bar of soap and a junk
CD-ROM. (I think soap is easier to remove than lipstick.)
Nicol
------------------------------
From: [EMAIL PROTECTED] (Natarajan Krishnaswami)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 17 Jul 1999 15:33:05 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 15 Jul 1999 22:59:44 GMT, Peter Seebach <[EMAIL PROTECTED]> wrote:
> This is partially because "he" is a gender-neutral pronoun in English, while
> "she" isn't, and "it" is a pronoun for the inanimate. "he" is correctly used
> both for typeless entities and for male entities.
Quite a few English-language native speakers (and publishers) have
rejected that position. (Unlike programming languages, natural ones
are in a constant state of flux. ;-) The social context arising from
the women's equality movement has precipitated, at least in the US, a
dramatic reduction in use of masculine pronouns, compounds of 'man,
etc., in generic contexts, and a fairly widespread (if mild) antipathy
towards their use as such. It's not inconceivable that in another 20
years, it may be considered poor style ("agrammatical") to use them
that way (here).
> Another argument against overloading words.
Quite.
<N/>
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: A few qustions on encryption
Date: 17 Jul 1999 16:26:42 GMT
Hi,
You neglected to tell us what type of encryption algorithm you were using
in the first place. And what mode of encryption was being used...
Keith
Krishna Sawh ([EMAIL PROTECTED]) wrote:
: I took two text files (file1 and file2) both the same contain the
: same data and the same size (50k), but file2 has one byte which is
: different. I encrypted the both files with the same key, when I
: compared each byte of the encrypted files I found all but 300 bytes
: were the same, I was just wondering if an algorithm exist that
: would encrypt file2 and be 99% different?
: Would this be a good form of encryption, if an algorithm dose not
: exist, where would I start in writeing one?
: Krishna Sawh
: [EMAIL PROTECTED]
:
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Subject: Re: NBE: Not crackable by brute force key search
Date: Sat, 17 Jul 1999 17:12:34 +0100
Reply-To: [EMAIL PROTECTED]
But surely, if any method of deciphering ends with the plaintext,
regardless of how, the code itself is broken, even if only for this
instance. Tom pointed out in an earlier discussion, any algorithm can be
beaten by brute force, you just use the algorithm and churn the
potential keys through it. So the only arbitrary factors in brute-force
cracking are the time required for execution of the algorithm, the
volume of possible keys and the level of access you have to the
components of the encryption method.
Just my tuppence,
James
------------------------------
From: "DoktorWHO" <[EMAIL PROTECTED]>
Subject: Deal for cracking !
Date: Sat, 17 Jul 1999 21:57:46 +0530
Hello there !
I've developed a crypto and want to test its stability !
If anyone is interested, lemme know..
{200$ for the first one to crack !!}
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: NBE crap and snake oil
Date: 17 Jul 1999 16:36:04 GMT
I haven't looked at that Virtual Calc (and don't plan to) but doesn't this
Numerical Base Encryption just stink of snake oil?
I'll bet you I could compare that snake oil faq and get about a 90% hit...
Keith
P.s. I haven't seen scottu19 or whatever the heck that other snake oil is
around lately, whats wrong? :)
------------------------------
From: "User" <[EMAIL PROTECTED]>
Subject: Re: Not crackable by brute force key search
Date: Sat, 17 Jul 1999 09:58:42 -0700
User <[EMAIL PROTECTED]> wrote in message
news:EBUj3.7$[EMAIL PROTECTED]...
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> Newsgroups: sci.crypt
> Sent: Friday, July 16, 1999 5:38 AM
> Subject: Re: Differences in binary-based conversions.
>
>
> > <snip>
> > Most algorithms and protocals
> > work on a fixed sized input. If your output is a different size I
> > could guess at what it was. Remember that the output must have the
> > same number of bits as the input. It doesn't matter how you print it
> > on the screen!!!
>
>
> Excuse me? I believe most cryptographers value chaotic distributions
> rather than finely conformed repeatable patterns. In this case, having
> output same as input would certainly limit the uncertainty of numeric
> distribution, thereby increasing the likely hood of an attack based on
> known values and patterns. Take a garage door opener with a fixed
> sized number of values. Permutating through all the values will yield you
> the correct one by brute force. Not knowing the size of values, you
> are unable to break it because you do not know the key size.
>
> Example:
> The key to a garage door opener is... 00000100
> It is expecting 8 bits.
>
> If you know the key size, you can permute through all the permutations
> in that space. Eventually you will get it.
>
> If you dont know the key size, you send 100, it is not going to open it
> because you are only sending 3 bits! You need to send 8 bits total.
> (it is expecting the 5 zeros in front of it).
>
> Now here is the important point...
> sending 100 will not open it.
> Sending 0100 will not open it.
> Sending 00100 will not open it.
> Sending 000100 will not open it.
> Sending 0000100 will not open it.
> Sending 00000100 WILL open it <------ bingo
> Sending 000000100 will not open it.
> Sending 0000000100 will not open it.
>
> So it is important that you do not fix your input and output size to
> a relation to each other. Numerical Base Encryption (NBE) (using
> virtual calc) allows you to
> convert to different bases (either up or down), thereby allowing
> you to have variable sized encryptedtext, and an unknown plaintext.
>
> If you dont know the plaintext base (an analogy to the keysize above),
> you can't open it no matter if you get the correct binary bits.
>
> Please do try out Virtual Calc and understand it more, that way
> you can make statements with a WORKING program to verify
> whether what you are saying is correct or not...
> http://www.edepot.com/phl.html
>
>
> >
> > i.e
> >
> > 12341234 (dec)
> > 57047762 (oct)
> > 101111000100111111110010 (bin)
> >
> > Note that the octal version looks more 'random'. But the binary
> > representation will never change!!!
> >
> > Just because I don't know your base doesn't mean I can't get access to
> > the binary version of the message. It's always there.
> >
>
>
> Aww... now you are coming around to understanding it more...
> You see... that binary representation can be gotten through traditional
> conversion, or numerical base conversion (NBC). Which one is it?
> (I hope you now understand the differences). And now for the good
> part... Where is the start of the conversion, and where is the end?
> If I gave you a stream of text...
>
> 123456789, where is the beginning of the NBC number?
> Where is the end of the NBC number? They can be padded in beginning
> and end with any character. And even if it was converted to binary
> (and suppose padding uses traditional conversion), you still don't know
> where to begin. This is very practical for STREAMING CYPHERS.
> In the example above, my NBC number can be...
>
> 234
> 345
> 456789
> 123456
> 456
> 12345678
> 6789
> ANYTHING!
>
> Lastly, lets say you half-randomly guess correctly the NBC number,
> now you have to worry about the algorithmic conversion.... (remember
> the operators?) THEN YOU HAVE TO WORRY ABOUT THE CORRECT
> BASE to convert to!!!
>
> Did I mention that the base can have duplicate symbols for high base
> numbers?
> What then? You can guess up to base 100, base 200, base 10000, it
> becomes exponentially expensive to try to crack it. In fact it is
> considered
> NP HARD (well, I rather call it NP VERY HARDCORE). Which means its
> not crackable by brute force. NBE is the only encryption method that is
NOT
> crackable by enumerating through all the keys, because its exponentially
> expensive, and you must know the exact base. (see garage example above)
> The keysize is not known... so it is like trying to find a needle that has
> melted
> in lava. :)
>
> Download it and try it out, you will see what I mean.
> http://www.edepot.com/phl.html
>
>
> >
> > I don't see this as a good idea. Even if you only send me the ascii
> > conversion there are not alot of bases to try before I get the
> > message. You can't for example use a base larger then the message or
> > it won't change it. You can't use a base that's too small either...
>
> I believe I left a message for unbelievers in the last posting.
> In that example I did use a base larger than the message.
> Encrypted text was base 64 while the plaintext was base 36. It will also
> work
> the other way around... From your statement I am guessing you
> either don't understand how it works at all, or you are simply
> making wild guesses with, again, no understanding of the subject.
>
> I suggest you try using the program before making wrong conjectures like
> this.
> Its a free download... http://www.edepot.com/phl.html
>
>
>
> Here is a message encrypted with Virtual Calc...
> 1.9wy1cbc43ktxmkkgk16c3brk9
> 8p6rdjtqlz0qatphelu7mqtbrosm1
> v2tfzv5b9e489vmspatscy1e3xip
> c5666c2qqh6rvoe6k8
>
> The plaintext describes certain people on this
> newsgroup. :) hehe.
>
> Try cracking it (seriously). Its very strong.
> Because I wanted to make this easier for others, I used
> the same operators as before but
> in this case I used base 64 as plaintext
> and base 36 as encrypted text (I reversed it). That way you can see
> that it does not matter what the size of the base is
> converting up or down, they are both strong.
> So if you want to know
> what I said in plaintext, grab virtual calc, click BASE,
> select 64. Press ok.
Oops. select 36, not 64. (we are doing the opposite as previous post,
going from lowerbase number to higher base number)
>
> Enter 1/MESSAGE in the expression box, where
> message is the above encrypted text. Press calculate.
>
> Click BASE, select 36, press OK.
Oops. Select 64 not 36. (64 is the base of plaintext)
>
> Voila! Your plaintext.
>
> And to answer questions regarding unused ascii characters in values 1-32
> and others, Virtual Calc supports symbolic remapping... You can
> use base 26 for your whole alphabet, (just click on BASE, select
> default symbols, enter a-z, press ok). Voila! OR, use base 27 (add
> another symbol), OR use base 28 (add 2 symbols), OR use base 52
> (a-zA-Z). You can map your own standard. I just happen to conveniently
> use 0-9a-zA-Z as default mappings... Which is configurable to your
> tastes. This is the second time you have falsely stated something without
> even understanding NBE, or trying out an ACTUAL IMPLEMENTATION
> of it. I hope this is not a true reflection of your credibility. The URL
> is again... http://www.edepot.com/phl.html
>
> Thanks.
>
> >
> > Tom
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Share what you know. Learn what you don't.
>
>
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Quantum Computers
Date: 17 Jul 1999 16:23:39 GMT
Bill Unruh <[EMAIL PROTECTED]>:
> Greg Ofiesh <[EMAIL PROTECTED]>
>> Let us begin with the following assertion that I think you will all
>> agree with. If a quantum computer exists, then the only form of
>> encryption that cannot be broken by it, or at least has half a chance
>> to survive an attack, is OTP. [...]
> Of course you can make all the assertions you want. The question is
> whether they have any basis in fact.
> Your first assertion is wrong. There is no known quantum algorithm for
> breaking any but the cryptosystems based on discrete logs and factoring.
That assumption is indeed wrong (it's the second assumption actually,
the first being that everyone would agree -- which is obviously wrong
given that this is Usenet :-). However it is not true that algorithms
are known only for factoring and discrete logs (both by Shor): there
is also Grover's algorithm for "database search" [STOC '96, 212--219],
which allows a speed-up from O(N) (brute force) to O(sqrt(N)).
Applied to symmetric cryptosystems, this roughly means that you need a
256-bit key to obtain the same protection against quantum computers
as a 128-bit key offers against classical computers.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: randomness of powerball, was something about one time pads
Date: Sat, 17 Jul 1999 20:00:14 +0200
[EMAIL PROTECTED] wrote:
>
> A simple way to analyze this is to use colored dice (RGB). Throw them
> 216 times. Ignore the combinations and inspect the payoff from each die
> independently. The red die matches your selection 36 times. Ditto for
> the green and blue die. Total payback in $108 against $216 in bets.
>
> The house wins. Big.
>
Completely wrong analysis....
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "donald tees" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Sat, 17 Jul 1999 13:29:29 -0400
Natarajan Krishnaswami wrote in message ...
>On Thu, 15 Jul 1999 22:59:44 GMT, Peter Seebach <[EMAIL PROTECTED]> wrote:
>> This is partially because "he" is a gender-neutral pronoun in English,
while
>> "she" isn't, and "it" is a pronoun for the inanimate. "he" is correctly
used
>> both for typeless entities and for male entities.
>
>Quite a few English-language native speakers (and publishers) have
>rejected that position. (Unlike programming languages, natural ones
>are in a constant state of flux. ;-) The social context arising from
>the women's equality movement has precipitated, at least in the US, a
>dramatic reduction in use of masculine pronouns, compounds of 'man,
>etc., in generic contexts, and a fairly widespread (if mild) antipathy
>towards their use as such. It's not inconceivable that in another 20
>years, it may be considered poor style ("agrammatical") to use them
>that way (here).
>
"It" has never been that way in English either. "it" is the genderless
pronoun, whether talking about bugs or cats. "It" has nothing to do with
animation ... she/he/it choices have to do with gender, and have for at
least since Chaucer.
Mare stallion horse
she he it
bitch dog canine
woman man human
Get it? It is quite simple, really. Perhaps your mommy can get you a book
from the library.
------------------------------
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
From: [EMAIL PROTECTED] (Peter Seebach)
Date: Sat, 17 Jul 1999 17:07:27 GMT
In article <[EMAIL PROTECTED]>,
Natarajan Krishnaswami <[EMAIL PROTECTED]> wrote:
>On Thu, 15 Jul 1999 22:59:44 GMT, Peter Seebach <[EMAIL PROTECTED]> wrote:
>> This is partially because "he" is a gender-neutral pronoun in English, while
>> "she" isn't, and "it" is a pronoun for the inanimate. "he" is correctly used
>> both for typeless entities and for male entities.
>Quite a few English-language native speakers (and publishers) have
>rejected that position. (Unlike programming languages, natural ones
>are in a constant state of flux. ;-) The social context arising from
>the women's equality movement has precipitated, at least in the US, a
>dramatic reduction in use of masculine pronouns, compounds of 'man,
>etc., in generic contexts, and a fairly widespread (if mild) antipathy
>towards their use as such.
Oh, certainly. However, I disapprove of political changes to languages.
That change breaks too much existing code. A lot of people have decided to
"reject" that position, mostly based on made-up etymologies or false claims
about the historical origins of our current set of words.
Essentially, I treat these people the same way I treat anyone who tries to
redefine words to fit a political agenda.
>It's not inconceivable that in another 20
>years, it may be considered poor style ("agrammatical") to use them
>that way (here).
It would be a shame, though, because we'd lose a lot of very expressive text.
"Man's inhumanity to man" is a much more elegant phrase than anything you can
do once you lose that usage.
In my own work, I mostly use 'he' as a gender-neutral pronoun, but
in the Hacker FAQ, I switch pronouns every question to keep people on their
toes.
(Curiously, I get flames about this; not on the grounds that "he is gender
neutral", but on the grounds that "there aren't many female hackers". I don't
know, but I'm guessing none of the people complaining are female or over 18.)
-s
--
Copyright 1999, All rights reserved. Peter Seebach / [EMAIL PROTECTED]
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
------------------------------
From: Rainer Hillebrand <[EMAIL PROTECTED]>
Subject: pure perl solution for Blowfish, DES or IDEA?
Date: Sat, 17 Jul 1999 19:53:58 +0200
Does anyone know a pure perl solution for Blowfish, DES or IDEA? I can't
install the known modules on the web server because I only have a ftp
access to my web server. Even if a pure perl script is rather slow it is
better than nothing.
Best regards,
Rainer
------------------------------
** 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
******************************
