Cryptography-Digest Digest #335, Volume #13 Fri, 15 Dec 00 09:13:01 EST
Contents:
Re: Visual Basic Source Code (Paul Schlyter)
Re: Visual Basic Source Code (Paul Schlyter)
Re: Protocol for computer go (Francois Grieu)
Re: [Question] Generation of random keys - LONG - algorithms, randomness and
unpredictability ("Andrew Vincze")
Re: Software PRNG.. (Jorgen Hedlund)
Encryptian of data over radio transmission ("Jordan McCallum")
Re: Sr. Cryptographer/mathematician (Tom St Denis)
Re: Software PRNG.. (Jorgen Hedlund)
Re: Crypto Program for HP48GX Calculator (Paul Makeev)
Re: Homebrew Block Cipher: Moonshine (Tom St Denis)
Re: Yet Another Challenge ( I hope ! ) (Kirk Whelan)
How secure is this (Kirk Whelan)
Re: Software PRNG.. (Richard Heathfield)
Re: Protocol for computer go (Anders Thulin)
Re: Homebrew Block Cipher: Moonshine ("Sam Simpson")
Re: weten we die PIN? ("Erwin Graumans")
Re: weten we die PIN? ("Erwin Graumans")
Re: Sr. Cryptographer/mathematician (JPeschel)
Re: weten we die PIN? ("Erwin Graumans")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Visual Basic Source Code
Date: 15 Dec 2000 10:40:53 +0100
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".....
2. VB is non-standard
3. VB is non-portable
I guess that sums it up.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Visual Basic Source Code
Date: 15 Dec 2000 10:41:30 +0100
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?
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Fri, 15 Dec 2000 11:40:16 +0100
[EMAIL PROTECTED] (David Wagner) wrote:
> David Eppstein wrote:
> >How is it prevented? The program in cheating-game-play mode has a
> >variable
> >that cycles through the possible moves, and when it sees a hint it waits
> >until the variable comes round to the right move then outputs the move
> >given by that variable.
>
> That's prohibited, because the program must be a deterministic function
> of the initial inputs and the moves of the other player.
Now I get what David means: the counter should be in sync on the main
program and on the replay program, without info from a transcript.
In essence, he propose that the program together with its counter is
deterministic and identical on both sides.
How do we implement the counter ?
No hardware counter works (deltas of QueryPerformanceCounter in Win32
are not even reproducible on one given machine).
The only solution I see (I welcome others) is that the programmer
knows the duration of each piece of code and maintains a global
variable updated accordingly, building a deterministic evaluation
of time (with some safety margin to avoid disqualification).
Consumes effort, some code, and some time, but feasible.
It implements a near equivalent of (c) and sortof (f) [as well
as (a) (b) (e)].
Now what about (d) ? Problem is, of course, that the behaviour of the
main program depends on when the adversary has played (especialy when
the program runs out of time).
Francois Grieu
>From the message that started the thread:
The goals of a protocol could be stated as:
(a) detects cheating, that is a human player helping the program,
for example using covert input channels.
(b) allows using machines supplied by the competitor, without prior
inspection by a referee, including remote play by Internet.
(c) allows programs to adapt their strategy to the time left.
(d) allows programs to compute while their opponent does.
(e) puts reasonable constraints on the referee.
(f) puts reasonable constraints on the programmer, including
not disclosing the source at all, or how the program works,
not even to a referee.
(g) [if at all possible] do not even ask the programmer to give
a fully usable executable to the referee; it might however be
acceptable to assume the referee will not let the executable
be reverse engineered, if unavoidable.
(h) [if at all possible] allow to run a match between two machines
without requiring a third trusted referee machine, even if
dispute can then occur regarding overtime.
(i) [if possible] allow the program to learn and improve during
a tournament.
(j) [if possible] allow the program to adjust its strategy
according to results of a tournament.
(k) [if possible] make the referee unable to help cheating.
------------------------------
From: "Andrew Vincze" <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys - LONG - algorithms, randomness and
unpredictability
Date: Fri, 15 Dec 2000 11:20:09 GMT
Bravo, John A. Malley! A beautiful, rigorously correct definition of
randomness!
David Schwartz: yes, you hit it right on the nose: When arguing about the
color of snow you must indeed be sure that you and your opponent mean the
same thing by color, by snow, and by black and white. Misunderstandings
have been known to start wars.
Your arguments are based on the relatively recent practice of extending the
definition of randomness to include other characteristics of random
sequences of numbers which are particularly useful to a great many
applications (e.g., uniform distribution) in addition to, and as divorced
from, the randomness itself. The definition of the word random now includes
"pseudo-random," so that now things which are random - in the original sense
of the word - must be identified as "truly random" so as not to be confused
with things that have only recently become random - by way of recent
extension - even though there is very little random - in the rigorous
sense - about them.
A quick consult with the dictionary reveals that "random" simply means
without method or aim (well, in plain English, anyway).
I believe we all understand the underlying principles, however, and would
agree there is no point in cryptanalyzing a sequence of numbers produced by
a roulette wheel, nor would it be much fun to "randomly" select where to go
for lunch by restarting the same pseudo-random algorithm with the same seed
every day (well, unless you really like the place it always recommends).
-Andrew Vincze
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Software PRNG..
Date: Fri, 15 Dec 2000 13:46:47 +0100
Reply-To: [EMAIL PROTECTED]
Simon Johnson wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > The conclusion of this is that with today's computers, one needs to
> > (in best case) take some random occurrance in the analogue world and
> > use this to produce randomness in the digital world. Although with
> > today's methods there are not really a 1-to-1 connection between the
> > analogue world and the digital; the "data" has to be converted before
> > entering the computer itself (via I/O). One far fetched (?) idea would
> > to use the random analogue "data" to affect the hardware of the
> digital
> > world (not using A/D converters though). How this should be done, I've
> > no idea...
> Yes, for key generation and other such applications, you are correct.
> But there is quite alot of entropy in the computer, its just harder to
> exploit.
And what is this "entropy" that everyone speaks about in this NG?
Could it be "randomness"? If so, then I understand the statement. ;)
BR/jh
------------------------------
From: "Jordan McCallum" <[EMAIL PROTECTED]>
Subject: Encryptian of data over radio transmission
Date: Fri, 15 Dec 2000 22:54:13 +1000
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
thanks
jordan
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Sr. Cryptographer/mathematician
Date: Fri, 15 Dec 2000 12:41:16 GMT
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!
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Re: Software PRNG..
Date: Fri, 15 Dec 2000 13:57:58 +0100
Reply-To: [EMAIL PROTECTED]
Terry Ritter wrote:
>
> You could do worse than to examine the basic statistics definitions in
> my Glossary, e.g.:
>
> http://www.io.com/~ritter/GLOSSARY.HTM#Statistics
> http://www.io.com/~ritter/GLOSSARY.HTM#Distribution
>
> each of which has many links to related terms.
>
> If you have trouble with this material, I would be interested in
> knowing what, if anything, could be done to improve the material for
> someone like you.
Ouch.. I checked it out briefly. Well, the only problem I've
discovered so far is the fact that the information size is
huge.. d'oh! .. I feel like it's way too much to dig into at
this point.. but eventually.
Also, the fact that I want to print stuff like this and read
it offline (yes, I'm still a lousy modem user) I'd like to
have it structured in different ways than available at the site.
All these links also makes it really difficult to read, one needs
to follow the links all the time.. especially newbies like myself.
(although most of them link to the glossary, which is great..)
After reading this NG for a short while I feel that my knowledge
and understanding has increased exponentially. It's good that
a "reference" site like yours are available, but as a modemuser
I can't possibly be connected all the time while I'm programming.
This leads to the suggestion about some tarball containing many
different topics.. available for offline reading..
Well, not really any comments of the material itself, but I hope
it's worth something...
Thanx, and BR/jh
------------------------------
From: [EMAIL PROTECTED] (Paul Makeev)
Subject: Re: Crypto Program for HP48GX Calculator
Crossposted-To: comp.sys.hp48
Date: 15 Dec 2000 13:00:37 GMT
In comp.sys.hp48 [EMAIL PROTECTED] wrote:
: Hi,
: I am looking for some crypto programs for the HP48GX. I am interested in
: DES and RSA but any other would be good too, the new AES algorithms for
: example.
: Can anyone help?
: Thank you,
: Brice.
There is MD4 and MD5 code in S/KEY package for HP-48 by Steve VanDevender.
I do not think DES or RSA are good for HP-48, since they are rather hungry.
If it doesn't bother, you can just compile standard code using C cross-compiler.
Paul.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Homebrew Block Cipher: Moonshine
Date: Fri, 15 Dec 2000 12:55:30 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > > Again, I'm an amateur, and this is a homebrew cipher.
> >
> > All good, I'm an amateur too :-)
>
> I thought you were a professional here!?
Heck no. I am still in High School :-)
> > Are the "offset/stride" pairs key dependant? If so I smell
WEAKKEYS...
>
> No, it's not key dependent, I don't think I described it very well.
>
> It does several slice array cyclings for each shuffle, but each
shuffle
> is identical. There's just one shuffle per round.
Good this means at best you can optimize the shuffle for maximal
potential diffusion.
> I should probably replace this so called shuffling with something less
> regular, and have a different shuffling in each round (but, of course,
> with no key dependency).
Try replacing the shuffle with a single convolution (i.e a permutation)
that has additional properties that each byte affects each other after
X rounds (X -> 0).
> Laziness. Or, rather, more interested in other bits of the cipher,
so I
> was just lazy with this bit. I will come up with one of my own,
though,
> and (hopefully) learn from it (as you suggest).
Well I learnt quite a bit about sbox generation from several papers
(Don't read anything by the CAST team they suck!) and writting my own
program to make them (on my website). My new ciphers either use
Rijndael like sboxes (not the same) or randomly derived ones.
> > Permutations are not forms of diffusion. They are catalysts for it
> > however. A permutation is nothing more then a sparse linear system.
>
> True. My description was ambiguous, specifically where I said "pairs
of
> bytes are mixed together". What I meant was that the block was then
> treated as a set of pairs of bytes, where each pair is taken in turn,
> and the two bytes in a pair are mixed with each other.
This is where you want to optimize your shuffle!
> > Of course this becomes a MDS matrix so at least diffusion is optimal
> > here :-)
>
> Hooray! (I really will have to properly learn what an MDS matrix
is...)
Read Serge Vaudenay's paper "On the need for Multipermutations:
Cryptannalysis of MD4 and SAFER". A MDS matrix is a special form of a
(n,r)-multipermutation where n=r. Generally it means you two 2n
dimmension vectors of the form <x, F(x)> and <x', F(x')> and the number
of elements of each vector that differ is always at least n+1 provided
that x != x'.
In your case n=r=2 and if you change any input vector both must
change. If you change both, only one has to change on the output but
both will with higher probability.
> > I really haven't looked at it deeply. But it seems neat from an
> > offset. What were your goals? More secure? Faster?
> >
> > Tom
>
> My goals were:
>
> 1. Jump in at the deep end.
> 2. Learn some (but certainly only some) stuff from doing it.
> 3. Block and key size scalability (as in order of magnitude).
> 4. Implementational flexibility (hardware, software...).
> 5. Optimisational opportunities (limited memory, speediness...).
> 6. Block and key size variability (as in linear).
> 7. Toothbrush.
>
> Thank you for your helpful, critical perusal!
Well your welcome. You are taking on quite a bit in your first
cipher :) Personally I like simple designs (such as TC5 :)).
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Kirk Whelan <[EMAIL PROTECTED]>
Subject: Re: Yet Another Challenge ( I hope ! )
Date: Fri, 15 Dec 2000 13:13:01 +0000
In article <91ajol$b9r$[EMAIL PROTECTED]>, Jeff Moser
<[EMAIL PROTECTED]> writes
>> 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
--
Kirk Whelan
------------------------------
From: Kirk Whelan <[EMAIL PROTECTED]>
Subject: How secure is this
Date: Fri, 15 Dec 2000 13:17:14 +0000
Originally from the thread Yet Another Challenge
In article <91ajol$b9r$[EMAIL PROTECTED]>, Jeff Moser
<[EMAIL PROTECTED]> writes
>> Hi everybody, as a result of watching this thread for a while,
>> and seeing the invites to see if things can be cracked.
>> Kirk
>
>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 don't know, 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.
the idea is that parms -f thru -n would be selected by two parties for
secure communication.
This also gives a little more info on how the cypherdigits where
derived.
Kirk Whelan
------------------------------
Date: Fri, 15 Dec 2000 13:19:48 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Software PRNG..
Jorgen Hedlund wrote:
>
> Simon Johnson wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > The conclusion of this is that with today's computers, one needs to
> > > (in best case) take some random occurrance in the analogue world and
> > > use this to produce randomness in the digital world. Although with
> > > today's methods there are not really a 1-to-1 connection between the
> > > analogue world and the digital; the "data" has to be converted before
> > > entering the computer itself (via I/O). One far fetched (?) idea would
> > > to use the random analogue "data" to affect the hardware of the
> > digital
> > > world (not using A/D converters though). How this should be done, I've
> > > no idea...
>
> > Yes, for key generation and other such applications, you are correct.
> > But there is quite alot of entropy in the computer, its just harder to
> > exploit.
>
> And what is this "entropy" that everyone speaks about in this NG?
>
> Could it be "randomness"? If so, then I understand the statement. ;)
Here's my semi-educated guess:
Cryptographic entropy seems to be a measure of "non-redundancy". If you
have N bits of data, and they are capable of representing 2 ** M (two to
the power M) different messages, then the data has M bits of entropy and
(N - M) bits of redundancy.
With regard to random numbers, it seems to work like this - if you're
generating random numbers using an unbiased octahedral die, you get
three bits of entropy per throw - i.e. you get three bits you could
legitimately assume to be unpredictable. If you're using pseudorandom
techniques, I think the amount of entropy you get is considerably lower
than 100% of the bits you generate.
Now for a explanation that doesn't involve randomness... Let's say we
have a code book with the following codes in it - codes which will be
transmitted in octets where, in each octet, the high bit is clear and
the low seven bits represent an ASCII code:
ATT - Attack
BIV - Set up a bivouac
OMO - Open your Movement Order envelope and follow the instructions
therein
REA - Re-arm weapons
REC - Reconnoitre
REF - Refuel
RET - Retreat
RLH - Run Like Hell
Here, we are using three octets, which is 24 bits of data. But we only
have eight different messages which can be communicated using this code.
Therefore, we have 3 bits of entropy and 21 bits of redundancy in this
code.
How did I do, folks?
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
Crossposted-To: rec.games.chess.computer
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Fri, 15 Dec 2000 13:11:23 GMT
Paul Rubin wrote:
> I have to say I've lost track of the proposal but I think the basic
> problem is this: Go-master Greg loses a game against the computer. He
> shouts "Damn cheating hunk of tin! No computer could *ever* have come
> up with that capture. You must have Anatoly Karpov (or his Go-playing
> counterpart) sending moves to it by wireless modem! I demand to see
> the instruction trace!" (This basically is what happened at the
> Kasparov-DB2 chess match). But what collected data can you give him
> that shows that the machine actually found that move?
Which is, of course, preposterous. Proving innocence is always
difficult. It should be the person who complains who should argue that
cheating did actually occur. What information does *he* need to prove it?
Relying on data coming from a system claimed to have been used for cheating
seems extremely doubtful, as that system very probably was designed
with cheating in mind.
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia ProSoft AB, Box 85, SE-201 20 Malmö, Sweden
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Homebrew Block Cipher: Moonshine
Date: Fri, 15 Dec 2000 13:35:51 -0000
"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?
Rgds,
Sam
------------------------------
From: "Erwin Graumans" <me@home>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Fri, 15 Dec 2000 14:44:30 +0100
> 300 Baud zou ik niet snel willen noemen.......... en de meeste PIN
> automaten en apparaten hebben een 300 Baud modem + een veredelde
> telefoonlijn naar de bank.
300 Baud?? Dat is allang achterhaald: het gaat via huurlijnen met een grote
bandbreedte.
> 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. En zelfs al zou je de codering kunnen achterhalen hoe wil je dan
je transacties uit die geldautomaat krijgen??
> De reden waarom we nog altijd redelijk veilig zijn is omdat criminelen
> economen pur-sang zijn: Het is (meestal) te veel moeite + risico voor
> te weinig opbrengst.
Daarom worden er nog altijd mensen beroofd bij de automaat en "slimme"
trucjes verzonnen om bij de gelduitgifte van de automaat aan het geld te
komen zonder dat het wordt afgeschreven, maar daar hebben ze ook al niets op
gevonden. Recentelijk zijn daar in de Randstad nog 18 mensen voor opgepakt.
> Grappig:
> Een kennis van mij heeft eens met zo'n winkelding gespeeld, het LCD
> display is gewoon lokaal programmeerbaar, theoretisch kun je dus na de
> transactie niet "Bedankt" printen maar: "We hebben je centen, rot nu
> maar op!" ;-)
Nou daar zul je je klanten echt mee houden...
------------------------------
From: "Erwin Graumans" <me@home>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Fri, 15 Dec 2000 14:47:56 +0100
Dat heeft geen enkele zin, omdat de PIN-code niet op de pas staat gecodeerd.
Vergeefse moeite en verloren tijd dus.
"David Dylan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 7 Dec 2000 22:09:58 GMT, John <[EMAIL PROTECTED]> wrote:
>
> Hoi hoi,
>
> >Geen van beiden, het wordt namelijk op de kaart zelf bijgehouden.
>
> Dat is wel het meest logische vanuit een efficiency standpunt, maar is
> het ook veilig? Inbreken in een banksysteem lijkt mij een end lastiger
> dan op je gemak in een achterkamertje met een paar nerds de code op
> een kaart uitdokteren... Of zie ik dat nu helemaal verkeerd?
>
> Je verzamelt een paar kaarten waar je de PIN van weet, en kijk &
> vergelijk... (simpel gezegd)...
>
> Groetz.
> DD.
>
>
>
> --
> Kijk eens op mijn community site:
> http://www.grep.nu/beleggers
> Of op mijn persoonlijke site:
> http://www.xs4all.nl/~nobeard
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 15 Dec 2000 13:51:49 GMT
Subject: Re: Sr. Cryptographer/mathematician
Tom St Denis [EMAIL PROTECTED] writes:
>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!
You need to pay more attention in school and less to sci.crypt.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Erwin Graumans" <me@home>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Fri, 15 Dec 2000 14:53:04 +0100
M.a.w.: de PINcode is veilig zolang de bezitter ervan zijn mond kan houden.
Geef daarom nooit je PIN-code aan een ander en zorg dat niemand op je
vingers kijkt als je hem intoetst.
Druk na een transactie ook nog eens wat andere toetsen in: er zijn gevallen
bekend waarbij criminelen zalf op de toetsen smeerden, zodat ze na een
transactie konden zien welke toetsen gebruikt waren. Daarna jatten ze de pas
en sloegen hun slag.
Maar bedenk altijd dat elke transaktie vanuit de bank te achterhalen is,
zowel datum, tijd als vaak ook degene die gepind heeft, omdat elke automaat
die gegevens bijhoudt en naar de bank stuurt en omdat bij vrijwel elke
geldautomaat een camera staat. Bij sommige automaten wordt zelfs door het
beeldscherm heen opnames gemaakt van de "pinner".... Je kijkt dan dus recht
in de lens!!
>
> Elke ontwikkelde code is kraakbaar, uitsluitend de factor " tijd " is
> de grootste belemmering. Ergo de pincode is nooit voor 100% veilig,
> doch om deze te kraken dien je wel de beschikking over de kaart te
> hebben, anders heb je 10.000 min 1 mogelijkheden.
> Ton
>
------------------------------
** 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
******************************
