Cryptography-Digest Digest #258, Volume #11 Sun, 5 Mar 00 13:13:01 EST
Contents:
Re: Crypto Speeds... ([EMAIL PROTECTED])
Re: Key escrow and echelon ([EMAIL PROTECTED])
Re: Decompiling/Tamper Resistent ("Kasper Pedersen")
Re: very tiny algorithm - any better than XOR? (Samuel Paik)
Re: ascii to binary ("Robert P. Rumble")
Security Features of Pokerspot.com (Tony L. Svanstrom)
avoid man-in-the-middle known plaintext attack using a stream cipher
([EMAIL PROTECTED])
why xor?(look out,newbie question! :) ([EMAIL PROTECTED])
Re: THE CIA ... please deport me ... or FBI/NSA or any of people ... please, I
have been in the USA too long .... I am on my way to Vladivostok as I have already
going there since 1990 or so .... it is my train .. your train is HUUHAA .. my train
is the LOVE train ... (James Pate Williams, Jr.)
Re: Decompiling/Tamper Resistent ([EMAIL PROTECTED])
Re: 'Free' services with tokens/puzzles (Ville)
Excel password remover ("Tobiass Mai")
Re: differential cryptanalysis (David A. Wagner)
Re: RC4 and salt (David A. Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Crypto Speeds...
Date: Sun, 05 Mar 2000 12:15:38 GMT
In article <MPG.132479671d267e24989680@localhost>,
Wei Dai <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > Is there any place on the Internet where we can find specific
> > information about speeds with specific processors and specific
> > operations? (Benchmarks, etc...). Fr example, what is the time
required
> > by Processor 'X' at speed 'Y' MHz to perform an hashing of a (say)
10Mb
> > document using (say) RIPEMD160?
>
> http://www.eskimo.com/~weidai/benchmarks.html
>
> It's for Intel Celeron running at 450 MHz, but you can download the
> benchmark program (part of a free crypto library) and run your own
> benchmarks on other processors.
>
Yes I looked at your site before..pretty good stuff....would be helpfull
to know timmings comparisons in handcoded assembler... just a
thuought...alot of work..
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key escrow and echelon
Date: Sun, 05 Mar 2000 12:36:32 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> hev wrote:
> >
> > Some PKI vendors are big on Key escrow, the storage of encryption
keys
> > in a "secure location." Some of these PKI vendors have intimate
> > relationships with big Echelon players (Defense Canada, NSA, DoD,
M15
> > etc). I've always wondered if these three letter agencies could get
into
> > the private key repositories. You may think you have a secure
connection
> > with your PKI or VPN, but if someone has access to the private
> > encryption keys, you are screwed.
>
> PKI suppliers have no need to see your private key. In fact, no one
> has.
> Don't give it to anyone. Don't do business with someone who asks for
> it,
> because they are surely very confused if they do...
>
> I haven't seen PKI vendors that are "big on Key escrow" as you claim.
Paul, sorry to disappoint you, but some of the biggest PKI names are so
centralised and into key escrow..it is scarey..I had a discusion with
one such big name recently in a conference..."Entrust"...
Not only do they generate your secret and public key pairs for you,
they also have a FULL history log of all your previous keys on the
server...a full backup....it is so centralised, unimaginable....
And they told me, in anycase they would not be able to get into the
server as there are only two ports..port 700 and another port..wink,
wink...They also do a direct update directly on your PC (Key Update) ...
Not only that, if you want to develop third party aps, e.g. secure mail,
etc..you have to use their rapper or plugin module...
> That makes sense, because it would be professional/commercial suicide
> to take that position.
I agree..but they are doing it..would you recommed to a customer a PKI
system that generates secret keys ?????????????????????????????????
We asked Entrust for the source code for one of our customers ( a large
organisation) ...and they said "forget it..dont even ask....we never
give our source code away...."
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Decompiling/Tamper Resistent
Date: Sun, 5 Mar 2000 11:55:51 +0100
<[EMAIL PROTECTED]> wrote in message
news:89rrv7$opu$[EMAIL PROTECTED]...
>
> Please visit NCipher....and other hardware crypto vendors...not only do
> they keep their keys in tamper resistant boxes...but also their
> softwrare...
They would love to have ALL their software out of the box. But if they have
their software out of the box, the keys must still 'come to the software',
which means that the keys will have to be visible _outside_ the box, and
then you could just as well print it on a sticker.
BUT, tamper resistance is not low-cost these days, take the 'satellite smart
card cracking' people as an example. If they are 'freaks' (doing electron
beam litography,STEM-EE-reads, various sidechannel attacks), you are in
trouble.
My guess is that a programmable micro alone isn't going to keep your bits
away from the above 'freaks'. None has yet, and don't trust what the
manufacturer states - my experience.
Hehe. So if it's worth less than a free movie channel, try a micro.
(not 8751, COP, PIC16C8, PIC16F84. To my knowledge they're broken. Try to
find
something using fusible links instead of hot electron injection)
--
/Kasper Pedersen
[PGP 0xCAF1E27C, 49B0 F0F1 2A6E AEE8 4AAA 8672 D4B9 5F58 CAF1 E27C]
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: very tiny algorithm - any better than XOR?
Date: Sun, 05 Mar 2000 13:38:09 GMT
Anyone have any idea how secure RC5 is with a 16 bit block size?
I think I've got a 16-bit block size RC5 implementation down to
20 instructions for this microcontroller. (not having an assembler for
this processor, I'm not positive it is completely legal code, the
datasheet instruction set reference is wretched). The number of
rounds would be limited to 127 (but you would run into your
memory size limitation first anyway).
This doesn't include the key expansion, but that could be done
offline--instead of transmitting the key, you transmit the expanded
key.
Looks like extending to a 32 bit block size adds 7 instructions,
with a maximum of 63 rounds.
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
You dont know enough about X86 or kernel architectures to argue with me.
- <38b2dc12$0$[EMAIL PROTECTED]> "Leon Trotsky" to Terje Mathisen
------------------------------
From: "Robert P. Rumble" <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Sun, 05 Mar 2000 05:48:36 -0800
See Recommended USA Standard Code for Information Interchange (USASCII)
X.34-1967 (and predecessors) which define encoding some characters and control
codes into 7 (yes, only seven). I know of no standard encoding into eight bits,
other than adding parity.
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Subject: Security Features of Pokerspot.com
Date: Sun, 5 Mar 2000 16:02:29 +0100
[Followup-To: sci.crypt, rec.gambling.poker]
Hi there friendly people of sci.crypt, here I am with yet another forwarded
posting made by one of those friendly on-line casinos giving away free money
and with such good security, and true random numbers using this-or-that.
Anyone that feels like commenting? (Oh, and please honor the Followup-To :)
======= Begin Forwarded Message =======
Subject: Security Features of Pokerspot.com
From: Robert Boyd <[EMAIL PROTECTED]>
Newsgroups: rec.gambling.poker
Date: Wed, 1 Mar 2000 19:32:26 -0800
This post is in response to a couple of questions posted by several
newsgroup members concerning the state of security of online poker
cardrooms. At Pokerspot.com, we've designed our systems with security in
mind.
We'll be opening our gaming floor for play shortly, starting things off
with a $22,000 promotion. Please check out our website for more
information, and to sign up for our notification list.
Now on to our security features:
- Firstly, all connections between our client software and our server
software are encrypted using session-key cryptography (using the
openssl-0.94 libraries). SSL is the standard for encrypted communication on
the Internet. All interaction with our website is also secure, and we have
acquired a secure certificate through Thawte Consulting (a trusted Internet
certificate authority).
- All user passwords are stored in encrypted form (using DES encryption) in
our databases.
- Our gaming software has been designed to deter collusion, by creating
actual tables dynamically. Pokerspot is the only online cardroom currently
using this scheme. A new table is created depending on the length of
the waiting list for a specific game type/limit combination. This makes it
more difficult for players to team up and decide which table to "attack".
- We have developed scripts that analyze hand logs to help recognize
collusion, and signatures of cheating. Pokerspot staff will be
automatically notified if our scripts detect suspicious behavior.
- Finally, our random number generator has been designed to be completely
non-deterministic. By utilizing a Geiger counter to detect radioactive
decay of
Americium 241 (a radioactive element, with a half-life of 432 years), we are
able to
generate true random numbers to drive our deck shuffling algorithm. This
makes Pokerspot.com the first and ONLY cardroom on the Internet with a
truly random number generator. For more information on this feature
(including our deck shuffling algorithm), please visit
http://www.pokerspot.com/random.html
We look forward to providing you with a secure and fun gaming experience!
Robert Boyd
Pokerspot.com, CTO
http://www.pokerspot.com
[EMAIL PROTECTED]
======== End Forwarded Message ========
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---���---���-----------------------------------------------���---���---
\O/ \O/ �1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: [EMAIL PROTECTED]
Subject: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: Sun, 05 Mar 2000 15:21:03 GMT
It's well known that in some case stream ciphers
are vurnerable
to a "meet in the middle known plaintext" attack.
This means that
if P xor S = C the attacker that known P can
obtain S and replace
P with an arbitrary P'. How is possible to avoid
this problem?
I'm not able to find some reference in litterature
but it *seems* that
if before to ecrypt every byte of P I perform some
simple nonlinear
transformation or some operation from a different
algebraic group
this attack become not possible. For example using
an 8x8 sbox
I encrypt with C = sbox[P] xor S
and decrypt with P = sbox[C xor S]
(This seems to work even using for example
addition modulo 256)
If This is secure is very useful in order to
encrypt for example
a TCP connection if you fear hijacking but I don't
known
if I'm right since I'm not a cryptographer.
The sbox can be obtained using the first bytes of
the keystream
and updated every X bytes, I hope this don't
violate the
U.S. patent 4,979,832
(http://www.io.com/~ritter/#DynSubTech).
Thanks for the attention. Comments are very
appreciated!
(sorry if you'll recive this message twice)
antirez
email: antirez@linuxcare<dot>com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: why xor?(look out,newbie question! :)
Date: Sun, 05 Mar 2000 15:43:48 GMT
I played with idea of making my own encryption
algorithm(haven't we all..),a basic thing,just for
fun,and I wanted to base it on pseudo-random
number generator,and using password for creating
seed.It would do something like:
cypher=(text + rnd)mod 256
on each byte of plain-text.Theoreticly,it should
produce uniform distribution of same interval as
rnd number,right?
Now some friends of mine tell me: No,don't use
that,use xor,everybodies using xor....
Sooo,now I wonder why is it,really,that there's so
many algorithms out there that choose to use xor
rather than some other method?Is it just for
speed,or because you can use a single function for
both encrypt and decrypt or there's something
more to it?
Thanx on reading this,
Ivan
ps.And when you already here,could you give me a
short comment on my initial idea of
encryption.What would be your line of attack,if
U need to decrypt it?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: THE CIA ... please deport me ... or FBI/NSA or any of people ... please,
I have been in the USA too long .... I am on my way to Vladivostok as I have
already going there since 1990 or so .... it is my train .. your train is HUUHAA ..
my train is the LOVE train ...
Date: Sun, 05 Mar 2000 16:09:43 GMT
On Sun, 05 Mar 2000 05:59:45 GMT, "Markku J. Saarelainen"
<[EMAIL PROTECTED]> wrote:
>
>THE CIA ... please deport me ... or FBI/NSA or any of people ...
>please deport me and replace me .. you can find some Mexican street drug
>runners or some other people .... I have been tired of being in the USA
>for years and I do not want to stay here .... I am on my way to
>Vladivostok as I planned in 1990 and I have already been going there
>since 1990 or so .... it is my train .. your train is HUUHAA (and a
>person C2 discussed this HUUHAA train with a person B4 .. :) HAHAHAHAHA
>) that was captured by my train .. my train is the LOVE train going
>through the whole Russia ... and this is my dream ...
>
>Yours,
>
>Markku
>
Have you considered having a private conversation with a pyschiatrist?
These USENET rantings are getting old. Newsgroups were trimmed to
sci.crypt.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Decompiling/Tamper Resistent
Date: Sun, 05 Mar 2000 16:02:38 GMT
In article <Vdtw4.35$[EMAIL PROTECTED]>,
"Kasper Pedersen" <[EMAIL PROTECTED]> wrote:
>
>
> <[EMAIL PROTECTED]> wrote in message
> news:89rrv7$opu$[EMAIL PROTECTED]...
> >
> > Please visit NCipher....and other hardware crypto vendors...not only
do
> > they keep their keys in tamper resistant boxes...but also their
> > softwrare...
>
> They would love to have ALL their software out of the box. But if they
have
> their software out of the box, the keys must still 'come to the
software',
> which means that the keys will have to be visible _outside_ the box,
and
> then you could just as well print it on a sticker.
>
> BUT, tamper resistance is not low-cost these days, take the 'satellite
smart
> card cracking' people as an example. If they are 'freaks' (doing
electron
> beam litography,STEM-EE-reads, various sidechannel attacks), you are
in
> trouble.
No, we are not trying to keep the Big Guys out...thats an impossible
task...only the small fish...One guy in a conference recently told me
that the government has a whole department doing discompiling and
nothing else...these guys are so good at it..they can turn any bits into
source code... ....
> My guess is that a programmable micro alone isn't going to keep your
bits
> away from the above 'freaks'. None has yet, and don't trust what the
> manufacturer states - my experience.
> Hehe. So if it's worth less than a free movie channel, try a micro.
> (not 8751, COP, PIC16C8, PIC16F84. To my knowledge they're broken. Try
to
> find
> something using fusible links instead of hot electron injection)
That sounds interesting...
What is interesting about the response to this thread is that clearly
the technology exists , but few know about it ...I used all the search
engines I could find... nothing...:-)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sun, 5 Mar 2000 19:50:14 +0200
From: Ville <[EMAIL PROTECTED]>
Subject: Re: 'Free' services with tokens/puzzles
On Sat, 4 Mar 2000, Adam Durana wrote:
> I don't see RSA's solution really solving the problem. Personally I think
> the folks at RSA saw how much attention the media was giving these recent
> denial of service attacks and hoped by claiming they had a solution to the
> problem, they would recieve some publicity. There are a few reasons why I
> don't think thier puzzle system will work. [...]
I have to pretty much agree.
Aside from your technical points regarding to puzzles as a DoS-prevention
measure, it's good to keep in mind the current nature of the distributed
attacks: CPU and bandwidth are already unlimited or soon about to become
that for the attacker.
There is no reason for them not to succeed in a pure resource-exhaustion
attack. I recently had to deal with PPark (a Windows virus/trojan). As I
pointed out on a few mailing-lists, there are ~90 000 infected boxes
currently active. If you get 90 000 boxes number-crunching (and make the
connections look exactly like the normal Windows-initiated ones), there
is not exactly a thing the remote end could do to stop it - or to even
slow the attack down. (attempting to route them dynamically to null
showed us a quick way to a table overflow...)
Oops, going off topic.
To stay on the subject, I'd just add we were not looking at this as a
direct DoS-prevention method. More as a way of rewarding the people
more committed to the project or that have been around longer. Not only
that, but I also found this something that could be interesting to
experiment with as it still seems a bit unexplored.
--
Ville([EMAIL PROTECTED], 'Cryptlink Networking);
------------------------------
From: "Tobiass Mai" <[EMAIL PROTECTED]>
Subject: Excel password remover
Date: Sun, 5 Mar 2000 18:52:13 +0100
Hello!
I've written a program which removes the protection of
Excel-workbooks/-sheets.
Can anybody tell me if i can get in trouble with Microsoft?
Regards
Tobiass
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: differential cryptanalysis
Date: 5 Mar 2000 09:22:29 -0800
In article <89lh3p$fpg$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> An attacker who apprehends or generates a sufficiently long cipher text, might
> choose to analyse blocks with a specific value of R. These blocks will be
> easy to find (unless R is say at least 64-bit, but then the band width of the
> cipher text will be increased accordingly).
No, it's worse than that. Any attacker *in a chosen-ciphertext model*
will get to *choose* to send blocks with a specific value of R. No matter
how large R is, the attacker can choose whatever value he likes and use
it for every chosen ciphertext he injects on the wire.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: RC4 and salt
Date: 5 Mar 2000 09:27:32 -0800
In article <89oajs$ajf$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <Pqwv4.2411$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > I have a question about implementing "salt" with RC4. Basically, what
> > is the standard method?
>
> Just append a 32-bit tag to the session key when you encrypt/decrypt.
> You can even use the time() function if you don't want to code anything
> else. As long as each session key is unique [which is possible in this
> case].
No, that's not the standard method (I hope not, anyway!), and to me it
sounds scary and quite possibly insecure. (See Roos' RC4 analysis.)
Go read how SSL/TLS do it. Basically, they append a 32-bit unique tag
to the master key and *hash* them to get a RC4 session key.
------------------------------
** 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
******************************
