Cryptography-Digest Digest #336, Volume #13 Fri, 15 Dec 00 13:13:01 EST
Contents:
Need help with number generator ([EMAIL PROTECTED])
Help with code generator/Formula ([EMAIL PROTECTED])
Re: Visual Basic Source Code ("Jason Bock")
Re: Visual Basic Source Code ("Jason Bock")
Re: weten we die PIN? (Pim Schaeffer)
Re: Sr. Cryptographer/mathematician ([EMAIL PROTECTED])
Re: security by obscurity ... ([EMAIL PROTECTED])
Possibly another Encryption method - any thoughts ? (Kirk Whelan)
Re: Protocol for computer go (David Eppstein)
Re: Encryptian of data over radio transmission (Tom St Denis)
Re: Homebrew Block Cipher: Moonshine (Tom St Denis)
Re: security by obscurity ... (David Wagner)
NT4 Password ("Mike The Man")
Re: Custom Encryption Algorithm (Marc)
Re: Possibly another Encryption method - any thoughts ? (Simon Best)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Need help with number generator
Date: Fri, 15 Dec 2000 14:27:17 GMT
Here is my situation. I am trying to figure out a
formula/code for a number generator. I have 5000
pairs of the input number and the result.
Let me explain. a certain number X is entered
into a program. then it returns Y. I have 5000 XY
pairs. Can someone lead me to what I need to do
to find the formula that creates Y? Is 5000 pairs
enough?
Thanks,
Topkat0
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Help with code generator/Formula
Date: Fri, 15 Dec 2000 14:28:40 GMT
Here is my situation. I am trying to figure out a formula/code for a
number generator. I have 5000 pairs of the input number and the result.
Let me explain. a certain number X is entered into a program. then it
returns Y. I have 5000 XY pairs. Can someone lead me to what I need to
do to find the formula that creates Y? Is 5000 pairs enough?
Thanks,
Topkat0
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Jason Bock" <[EMAIL PROTECTED]>
Subject: Re: Visual Basic Source Code
Date: Fri, 15 Dec 2000 09:06:11 -0600
Paul Schlyter <[EMAIL PROTECTED]> wrote in message
news:91cp0a$78c$[EMAIL PROTECTED]...
> In article <3a39a408$0$75795$[EMAIL PROTECTED]>,
> Jason Bock <[EMAIL PROTECTED]> wrote:
>
> > People have done some amazing things in VB to break beyond its'
> > boundaries (i.e. they don't fear "real programming").
>
> If they don't fear "real programming", why don't they switch to some
> real programming language?
First, define "real programming language." What are you criteria? What
makes VB not a "real programming language"? BTW, technically VB isn't a
language, it's a tool (I admit in this thread I've been calling it a
language, but it's more of a language/tool combo).
You type in some code, you compile it, it runs on a Windows-based
workstation. I fail to see how that disqualifies it from being a "real
programming language."
Jason
------------------------------
From: "Jason Bock" <[EMAIL PROTECTED]>
Subject: Re: Visual Basic Source Code
Date: Fri, 15 Dec 2000 09:11:52 -0600
Paul Schlyter <[EMAIL PROTECTED]> wrote in message
news:91cov5$75j$[EMAIL PROTECTED]...
> In article <3a39a2f0$0$75802$[EMAIL PROTECTED]>,
> Jason Bock <[EMAIL PROTECTED]> wrote:
>
> > I'm not advocating VB - I'm interesting in why someone dismisses VB
> > outright.
>
> Mainly because of three reasons:
>
> 1. VB is based on BASIC, a programming language which ought to have
> become extinct long ago. But thanks to Bill Gates it's still here,
> more widespread than ever. Bill Gates once started out with BASIC
> (he wrote the first BASIC interpreted for the Mits Altair back in
> 1976 or so), and he returned to BASIC, incarnated as VB, ASP,
> WordBasic and possibly something else as well. "Basic forever".....
You need to do your homework on this one. First, saying that BASIC "ought
to have been extinct long ago" is purely a matter of opinion. Many people
think C++ should die in flames as well. Others hate Perl. Some eschew
Eiffel. But that doesn't disqualify the language in itself.
Also, ASP is NOT BASIC. You need to look at ASP harder. You can use any
scripting language in ASP, just as long as you have the correct interpreter.
> 2. VB is non-standard
So? Neither are a lot of languages. Doesn't bother a lot of people. BTW
define "standard." I know, submit it to ECMA or any other standards
committee. I fail to see why that excludes VB as it is not a standard
(there are many other languages that are not "standard").
> 3. VB is non-portable
Again, that's a personal taste. I could care less if my VB app isn't
portable. There are cases where you need to be portable - use Java which
claims to be WORA. But I've run into that kind of situation so infrequently
in my career, and I would argue that such a need isn't as big as some
industry experts claim it to be.
Jason
------------------------------
Date: Fri, 15 Dec 2000 16:33:52 +0100
From: Pim Schaeffer <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Erwin Graumans wrote:
> > Veilig zou ik dat ook niet willen noemen. Mits je de lijn kunt vinden
> > tussen de automaat en de PTT kast kun je de lijn met een simpel thuis
> > te bouwen apparaatje aftappen.
>
> En dan?? De data wordt zwaar encrypt met sleutels op transport en
> hardwareniveau. Voordat je de zaak encrypt hebt is/zijn de sleutels alweer
> gewijzigd.
Dat zijn session keys. Elke keer anders.
> En zelfs al zou je de codering kunnen achterhalen hoe wil je dan
> je transacties uit die geldautomaat krijgen??
Je wil een berichtje van de bank naar de automaat faken dat zegt
OK betaal maar uit.
Door de encryptie en sessie key is dat een vrijwel te verwaarlozen kans
dat dat lukt.
--
pim
Uw motormanagement systeem constateert dat het aantal passagiers
veranderd is. Wilt U de motor nu opnieuw opstarten?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Sr. Cryptographer/mathematician
Date: 15 Dec 2000 15:42:05 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> 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.
> I was right in the first place. "Your" is the flipside of "mine"
> and "You're" is the flipside of "I Am"
> So I could interpret it as "Mine better to ..." makes NO SENSE!
Damn, Tom, read what you're talking about above... The quote didn't
have the word "better" anywhere in it. The original posting was "Your
rather gritty usenet manner...." which you "corrected" to "You're
rather..."
You were wrong in that correction. You were wrong in the
clarification of your correction. And you were wrong again in this
last posting. All the material is quoted up above. READ it before
you make more foolish postings....
--
Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
Dept. of Computer Sciences | "The box said 'Requires Windows 95, NT,
University of North Texas | or better,' so I installed Linux."
Denton, TX 76201 |
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: security by obscurity ...
Date: Fri, 15 Dec 2000 16:09:10 GMT
Anders Thulin <[EMAIL PROTECTED]> wrote:
> There are many forms of that utterance now, and I'm not sure
> which is be considered to be the original one or the correct one.
> Indeed, it is in danger of coming close to be treated as a mantra -- to
> be repeated with as little conscious thought as possible.
> My interpretation of it is that obscurity is not sufficient for security.
> It may be a component of security, but it should not be the only component.
Which is the correct way of looking at it.
The entire phrase really seems to have taken on buzzword status
recently, with the increased interest in cryptography and computer
security. In fact, it seems to have leaped off the pages of a certain
popular author to be applied to everything under the sun.
It's a solid idea for encryption algorithms, although "no security
through obscurity" is actually closer to "peer review is essential for
security." There's no reason to believe, for example, that government
secrets are less protected than the contents of alt.anonymous.messages
by virtue of the fact that Uncle Sam uses secret algorithms.
As to stretching the point to complete systems, or things even further
removed, it doesn't always make sense. For example, my bank doesn't
tell me what model vault they use, or the location of every CCTV input
or monitor. Nor do they publish where the alarm pins out (just at the
manager's house? The police station? Fire Dept?) or what the expected
response time of anyone monitoring it is. Whew! Thank god for FDIC
insurance, with all this obscurity, my bank's really insecure.
The problem here, of course, is that "obscurity alone does not insure
security" does not imply "security requires the absense of obscurity."
As many people pointed out, the answer to the original question is of
course no, using a pile of home-brew algorithms isn't any better than
using established ones. On the other hand, if you can manage to
coordinate it, using a rotation of the five finalists and different
key lengths whenever possible probably wouldn't hurt. You would, of
course, need to avoid identifying headers and use an unpredictable
algorithm for choosing the encryption method of the day, which makes
it impractical for most everyone.
To me, it's interesting that the government typically employs a good
bit of obscurity, typically designed into the end system. (One of the
reasons stream ciphers are so popular for military applications). It's
possible, for example, to key a hardware device with a pair of keys,
one for the underlying stream cipher, and one which rotates the
transmission frequency based on the current time. Then, to receive the
entire message you need an identical unit with a syncronised clock and
matching keys.
Granted, in this particular example, anyone with omniscient knowledge
of all the variables could intercept the message so it's not really an
inpentrable kind of obscurity. The obvious goal of keeping as much
information as possible out of enemy hands is instructive however.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Kirk Whelan <[EMAIL PROTECTED]>
Subject: Possibly another Encryption method - any thoughts ?
Date: Fri, 15 Dec 2000 16:31:16 +0000
First off, my apologies for adding to existing threads "A Challenge", I
had not set my posting options correctly.
>> Hi everybody, as a result of watching this thread for a while,
>> and seeing the invites to see if things can be cracked.
>
>If you'd read the FAQ, you'd notice that unless you publish your source code
>and/or algorithm description with plaintext/ciphertext pairs, this request
>is worthless and no one will guess it. Security by obscurity is bad.
>
>Jeff
>
Thanks Jeff, if I gave the source would that not compromise what I am
trying to release? Only thoughts.
OK
kirk -> 75738275 -> nothing special there
formula for selecting primes abs(a^2-3b+5c)
formula for encoding enigma wheel are the product of any three of the
random digits used to select primes for targets for enigma encoding,
could be a simple equation as an alternative.
random
digits enigma primes
abc rotations used result
478 882 5 98085580429748297795545
758 798 3 8937746026760630608875813
876 868 4 078833242016486876778148887614
There's the guts of the encryption, so the question is how easy would
this be to crack. The reason for asking is because I am not a
mathematician, and since I designed the code I know where I would start.
So hence the request for help.
This is really going to lead to me issuing a programs for various
platforms for encoding & decoding.
The run time encryption line will look very close to the one listed.
KEP -rabc -f<fn> -e<ecm> -<pfn> -b<num> [-n<pc>] plaintext
where
ab+c are digits 0-9
fn is Fractionalisation table number 1-99
ecm is enigma coding method 1-99
pfn is primes selection formula number 1-99
num is a selected base number 0-9....
pc is the maximum number of primes to be considered and is optional.
This also gives a little more info on how the cypherdigits where
derived.
--
Kirk Whelan
------------------------------
From: David Eppstein <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Fri, 15 Dec 2000 08:41:13 -0800
In article <91clta$g6g$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David
Wagner) wrote:
> That's prohibited, because the program must be a deterministic function
> of the initial inputs and the moves of the other player.
So you're disallowing thinking while it's the opponent's turn?
If not, how do you account for the nondeterminism in the amount of time the
opponent takes?
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encryptian of data over radio transmission
Date: Fri, 15 Dec 2000 16:51:34 GMT
In article <Bfo_5.159595$[EMAIL PROTECTED]>,
"Jordan McCallum" <[EMAIL PROTECTED]> wrote:
> How can i encrypt voice data over FM. Schematics would be
appreciated.
> Basically looking for a addon for a FM transciever i have. Also
schematics
> for the decryptor
There is more to it then that. You need to input a key somehow or
negotiate one. You probably want to be a digital mode not analogue
either.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Homebrew Block Cipher: Moonshine
Date: Fri, 15 Dec 2000 16:50:09 GMT
In article <w7p_5.6333$[EMAIL PROTECTED]>,
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:91d4c2$p3p$[EMAIL PROTECTED]...
> <SNIP>
> > Well I learnt quite a bit about sbox generation from several papers
> > (Don't read anything by the CAST team they suck!)
>
> Interesting....Why do you say that Tom? I thought the CAST papers
were
> quite well recognised?
The cast ciphers are not particularly efficient or as secure as
possible. Take CAST-128. Replace the sboxes with a four 8x8 sboxes
and a MDS. The resulting cipher is much more secure. And the function
is a bijection.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: security by obscurity ...
Date: 15 Dec 2000 17:24:20 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
>To me, it's interesting that the government typically employs a good
>bit of obscurity, typically designed into the end system.
It makes sense for them. The govt has more in-house expertise
than is available from the open community.
However, most companies are in a different position. A typical
company has little in-house cryptographic expertise; the academic
world has orders of magnitude more expertise. In this setting, if
the company uses a closed system, they forfeit the possibility of
benefitting from the expertise of others. This is forfeiting a
very large and important benefit, and rarely is it worth it for
a widely-deployed, long-term system (IMHO).
------------------------------
From: "Mike The Man" <[EMAIL PROTECTED]>
Subject: NT4 Password
Date: Fri, 15 Dec 2000 18:39:49 +0100
Hi!
Could anyone explain to me how the clear-text password is encrypted in NT.
I understand it's Unicoded and then hashed with MD4, but it doesn't work
with my MD4-app.
If the password is 'a', shouldn't the Unicode be '6000' in hex?
If I feed 6000 into the MD4 it doesn't come out the same way as in
L0phtcrack?
So I guess there's something wrong with the Unicode (I've run all the tests
in the MD4 rfc in my app).
Thanks!
Mike
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Custom Encryption Algorithm
Date: 15 Dec 2000 17:44:38 GMT
>You appear to have missed one of my main points. I designed the program
>to protect my emails to my very close friends from ANYONE who would want
>to read an email from me to them. I beleive I have accomplished that.
>As I stated before, I beleive that more now than two weeks ago. And of
>course, there isn't the $10,000 incentive to read my email.
:-) Your email comm with your friends is very well protected from
me even without any encryption, because I don't care about it..
When selecting an algorithm and protocol, the cryptographer first
makes a threat model. He judges the weaknesses of the problem and
how much effort an attacker might come up with. The algorithm and
protocol are then selected in a way, that the attacker has to put
in considerably more effort than the secret is worth.
When protecting a $1 Million business secret, you use an algorithm
that requries >$1 Million worth of computing power to crack.
When protecting an incriminating confession that becomes unpunishable
in 10 years, you use an algorithm that is likely to remain strong
for 10 years (or select keysize acordingly for algorithms
like RSA).
If in you own case the threat model sais "all possible attackers are
casual net snoopers, noone will attack deliberately" and "this
casual attacker will do not more effort than starting up an ASCII
viewer", then even ROT-13 is an appropriate protection.
I have also used weak algorithms successfully in the past, because
the threat was even weaker than the algorithm.
------------------------------
From: Simon Best <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Possibly another Encryption method - any thoughts ?
Date: Fri, 15 Dec 2000 18:05:58 +0000
Hello Kirk!
Kirk Whelan wrote:
>
> First off, my apologies for adding to existing threads "A Challenge", I
> had not set my posting options correctly.
>
> >> Hi everybody, as a result of watching this thread for a while,
> >> and seeing the invites to see if things can be cracked.
> >
> >If you'd read the FAQ, you'd notice that unless you publish your source code
> >and/or algorithm description with plaintext/ciphertext pairs, this request
> >is worthless and no one will guess it. Security by obscurity is bad.
> >
> >Jeff
> >
> Thanks Jeff, if I gave the source would that not compromise what I am
> trying to release? Only thoughts.
When a system relies on people not knowing how it works for security,
that's called 'security through obscurity'. It's generally accepted
that it's a bad idea. Answer the following questions, in detail, to see
why it's bad:
1. What will you do if, during the lifetime of your cryptosystem, you
learn that an adversary has found out how your cryptosystem works?
2. What will you do if an adversary finds out how it works, but you
never find out that an adversary has found out?
3. What will you do if a once trusted person turns into an adversary?
4. How will you keep possible adversaries from finding out in the first
place?
5. How will you reduce risks from things that haven't even occurred to
you, me, or anyone else?
> OK
> kirk -> 75738275 -> nothing special there
>
> formula for selecting primes abs(a^2-3b+5c)
> formula for encoding enigma wheel are the product of any three of the
> random digits used to select primes for targets for enigma encoding,
> could be a simple equation as an alternative.
>
> random
> digits enigma primes
> abc rotations used result
> 478 882 5 98085580429748297795545
> 758 798 3 8937746026760630608875813
> 876 868 4 078833242016486876778148887614
I don't know enough about Enigma to really follow your description, but
I suspect it's weak if it relies on Enigma, as Enigma's already
(famously) broken.
> There's the guts of the encryption, so the question is how easy would
> this be to crack. The reason for asking is because I am not a
> mathematician, and since I designed the code I know where I would start.
> So hence the request for help.
Does this mean you already know how to break it? If so, then you
already know it's weak.
> This is really going to lead to me issuing a programs for various
> platforms for encoding & decoding.
Doesn't this mean that your system will be vunerable to reverse
engineering? Consider the five questions above.
> The run time encryption line will look very close to the one listed.
> KEP -rabc -f<fn> -e<ecm> -<pfn> -b<num> [-n<pc>] plaintext
> where
> ab+c are digits 0-9
> fn is Fractionalisation table number 1-99
> ecm is enigma coding method 1-99
> pfn is primes selection formula number 1-99
> num is a selected base number 0-9....
> pc is the maximum number of primes to be considered and is optional.
Is that how I'd use if from the command line? Why does the command line
need to have the key split up so explicitly?
Anyway, from that information, I can give you an (optimistic) estimate
of it's level of security (optimistic, because I'm assuming that brute
force key searches would be the only viable attacks). As you've given
no clear indication of the maximum number of digits for 'num', I'm
assuming just one digit there. Also, as 'pc' is optional, and seems to
be something that would limit your system, I'm ignoring that.
In terms of key size, it's got a strength of about 33 bits. That's very
weak. Eight billion keys (combinations of command line arguments) at
most (assuming a single digit for 'num', and no 'pc' argument). If I
could try out a million keys per second (on computers, of course), it
would take only a few hours to crack it. If I could try out only a
thousand keys per second (on a spare 386 PC, perhaps?), it would still
only take a few months.
My conclusion, therefore, (and I'm an amateur at this, too) is that your
cryptosystem is, at best, far too weak. Maybe that's disheartening, so
I suggest you take this as an indication that there's still lots more
interesting, even fascinating, stuff to learn about cryptology.
Simon
> This also gives a little more info on how the cypherdigits where
> derived.
> --
> Kirk Whelan
--
_______________________________________________________________________________
Personal: [EMAIL PROTECTED]
Yellow Skies: [EMAIL PROTECTED] http://www.yellowskies.com
Everyone does their own signature to be different. How does that work?
------------------------------
** 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
******************************
