Cryptography-Digest Digest #358, Volume #13 Mon, 18 Dec 00 04:13:01 EST
Contents:
Re: Use of multiplexing (Simon Best)
Re: Smart Card vs 1.44 Disk ("KumaSan")
Re: Math background required for Cryptology ? ("KumaSan")
DES,3DES overhead vs plaintext ("Adrian Grigorof")
Re: Software PRNG.. (kimpert)
Re: Encrypting messages in images?? ("lester burnam")
Re: Q: Result of an old thread? (Bryan Olson)
Re: DES,3DES overhead vs plaintext ("Scott Fluhrer")
Where does one find DSP professionals for jobs? ("premchi")
Re: Q: Result of an old thread? (Mok-Kong Shen)
Re: Use of multiplexing (Mok-Kong Shen)
Re: Protocol for computer go (Francois Grieu)
----------------------------------------------------------------------------
From: Simon Best <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Use of multiplexing
Date: Mon, 18 Dec 2000 05:19:39 +0000
Mok-Kong Shen wrote:
>
> Multiplexing is a rather old topic in CS. In the crypto
> context, it is also well-known (see spread spectrum, CDMA).
> I like to consider the issue presently, however, purely
> at the application level, i.e. whether a normal user, who
> does encryptions as usual, can profitably apply multiplxing
> techniques of his own.
Is this a user level thing, then?
> In plenty of situations one does not send occassionally
> single messages. Between two distant officies of a
> commercial firm, for example, a substantial amount of
> communications, usually of different security levels,
> occur.
So it's not at the user level, but at a network level. How about
encrypted IP over IP? Are you suggesting network packets get
multiplexed and then split into 'perpendicular' network packets? What
if network packets are infrequent? What if a whole load of network
packets arrive at the gateway but which all belong to the same
transmitted file?
> It is thus feasible to multiplex the messages,
> i.e. intermingling them in some secret (either fixed or
> dynamically varying) way that is unknown to the opponent,
> thus rendering his analysis job difficult. There will
> certainly be some appreciable cost/work involved for
> the partners doing multiplexing, but the resulting
> difficulty caused to the opponent could under circumstances
> justify that, I believe. I wonder thus whether such
> multiplexing has not already been successfully employed in
> practice.
>
> We note that multiplexing can be done at two different
> levels, (intermingling of plaintexts and of ciphertexts),
> and also at different granularity (word/byte/bit).
>
> M. K. Shen
> -----------------------------
> http://home.t-online.de/home/mok-kong.shen
It's an interesting idea, but there are those issues I asked about that
would need to be addressed, depending on the level at which such a
cryptosystem would exist.
Simon
--
_______________________________________________________________________________
Personal: [EMAIL PROTECTED]
Yellow Skies: [EMAIL PROTECTED] http://www.yellowskies.com
Everyone does their own signature to be different. How does that work?
------------------------------
From: "KumaSan" <[EMAIL PROTECTED]>
Subject: Re: Smart Card vs 1.44 Disk
Date: Sun, 17 Dec 2000 21:39:37 +0800
In article <90jrg4$ic9$[EMAIL PROTECTED]>, "JustBrowsing"
<[EMAIL PROTECTED]> wrote:
> Smart Card vs 1.44 Disk
>
> This is probably a really dumb question but once I get past all the
> smart card marketing, I cant see the advantages of a smart card over a
> 1.44 disk using good crypto techniques.
>
> I keep coming to this conclusion, once data has been securely locked up,
> does it matter what the medium is? Does giving the medium a "mind of its
> own" really make a difference.
>
> Just dont get it! For the sake of argument please assume all mediums are
> equal. For example, yes, 1.44 disks get messed up easily, mag stripes
> cant hold a huge amount of info etc. Get past that and tell me why smart
> card as a medium can do something a 1.44 disk and PC with reader cant?
>
> I'm thinking about setting up a travel agency voucher system... why must
> I buy expensive smart cards?
>
>
It seems that what you are saying is "Ignoring all the reasons that make
smart cards better than floppies for this, tell me why smart cards are
better than floppies"
Floppies die, they die easily, they are easily killed, they don't stand
up to 2 year olds as well as smart cards, puppies eat them, (ok, bad
comparison, puppies sometimes eat kitchen tile, don't ask...) you get the
drift. If you want to compare smart cards and floppies without
considering the longevity of same, be my guess, it's your business.
------------------------------
From: "KumaSan" <[EMAIL PROTECTED]>
Subject: Re: Math background required for Cryptology ?
Date: Sun, 17 Dec 2000 21:42:43 +0800
In article <[EMAIL PROTECTED]>, "M.S. Bob"
<[EMAIL PROTECTED]> wrote:
>
>> Information theory is often taught in electrical eng, and
>> you're better off taking some other signal processing courses
>> too. A course on signals and systems, a course on random
>> processes,
>
> Why do you recommend signal processing? I'm curious, as never having
> taken a signals course.
I'd say it's because signal processing is often involved in pulling the
most info from the poorest signal, much like cracking a crypto msg.
Random dist filtering methods, etc.
------------------------------
From: "Adrian Grigorof" <[EMAIL PROTECTED]>
Subject: DES,3DES overhead vs plaintext
Date: Mon, 18 Dec 2000 06:14:49 GMT
I am interested in finding information about the overhead in size/speed of
DES vs 3DES vs plaintext through TCP/IP. Is 3DES basically 3 x DES in speed?
How about the size of the final cipher, or CBC vs EBC?
Thanks,
--
Adrian Grigorof
Independent IT Consultant
Toronto, Canada
www.grigorof.com
------------------------------
From: kimpert <[EMAIL PROTECTED]>
Subject: Re: Software PRNG..
Date: Mon, 18 Dec 2000 06:51:07 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
> Are there any (good) software PRNG's on the net, that is also free?
>
> I've scoured the FAQ, but, well let's say that I didn't come up
> with anything by doing so..
>
> BR/jh
>
> PS!
>
> Excerpt from the only reference of PRNG (in sci.crypt), according
> to www.faqs.org:
> "...where Prngxor() [FTPPX] is a simple stream cipher driven from
> a long-period pseudo-random number generator (PRNG),..."
>
Here's one place to start. Actually, it was recommended to me in this
ng a few years ago for a simulation program I have. I wanted some
PRNG code that was fast and likely to be "more random" the the rand()
function in the MSVC++ library.
http://www.math.keio.ac.jp/%7Ematumoto/emt.html
It's called the Mersenne Twister. I am an application developer who
is in no way any kind of expert on the subject of PRNGs. The code
worked for me. YMMV
--
. . . . . . . . . . . . . . . . . . . . . . . .
Spammbait
root@localhost postmaster@localhost admin@localhost
abuse@localhost webmaster@localhost [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
Reply-To: "lester burnam" <[EMAIL PROTECTED]>
From: "lester burnam" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security
Subject: Re: Encrypting messages in images??
Date: Mon, 18 Dec 2000 07:18:52 GMT
http://www.innovatools.com/software/isecrets/index.htm
(free download version). Can be quite useful !!!
well i want to know why this program tries to call home?
anybody know why??
outbound attempted for (IPC SERVER
C:\WINDOWS\SYSTEM\MSIPCSV.EXE
ans2.adsoftware.com)
i blocked it of course. so why does it need to call
home? seems like a nice program but with it
calling home i decided no thanks and uninstalled it.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Result of an old thread?
Date: Mon, 18 Dec 2000 07:17:44 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> > Mok-Kong Shen wrote:
> > > And would such a B' be invertible?
> >
> > Some are. An invertible solution works in Best's solution
> > for S. We could of course solve for S using a system of
> > linear equations without worrying about choosing an
> > invertible solution for B.
>
> Just knowing some are invertible would solve the problem,
> I suppose, if one has to try extremely long.
What are you talking about?
> I don't
> understand your last sentence. Which system do you mean
> that you want to solve?
You see anything non-linear in the scheme? Is there enough
information to determine S? Does that tell you anything?
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: DES,3DES overhead vs plaintext
Date: Mon, 18 Dec 2000 00:05:04 -0800
Adrian Grigorof <[EMAIL PROTECTED]> wrote in message
news:tXh%5.146466$[EMAIL PROTECTED]...
> I am interested in finding information about the overhead in size/speed of
> DES vs 3DES vs plaintext through TCP/IP.
Good luck! Remember that "encrypting" a packet involves things other than
actually running the raw bits through the cipher -- things such as deciding
whether a particular packet should be encrypted, which key it should be
encrypted with, computing the MAC (you are going to use a MAC, right?)
> Is 3DES basically 3 x DES in speed?
Sorta/kinda. (I assume that you meant whether 3DES takes 3 times as long as
DES, rather than that it was 3 times faster)
- A software 3DES implementation only needs to have one initial and one
final permutation, and so it will be marginally faster than 3 separate DES
encryptions (which would require three initial and three final permutations)
- In addition, the encryption overhead (everything involved with encryption
except running the bits through the cipher) should be the same independent
of the whether you're using DES or 3DES, and depending on the packet size,
and the efficiency of the various operations, may be a considerable part of
the time taken.
> How about the size of the final cipher, or CBC vs EBC?
The size of the ciphertext should be identical between DES and 3DES. For
CBC mode, that depends on the ciphertext packet format -- it may include
padding to 8 bytes (unless you use a CBC varient that handles odd-sized
messages), and may include an IV (unless you are able to make it implicit).
You may also want to include room for a MAC tag (MAC's are really good
ideas), and some tagging information to help the receiver know that it is an
encrypted packet, and for what keys.
(You're not really thinking about running the cipher in ECB mode, are you?)
BTW: are you designing your own TCP/IP encryption system? Have you thought
about reusing an existing IPSec/SSL implementation?
--
poncho
------------------------------
From: "premchi" <[EMAIL PROTECTED]>
Subject: Where does one find DSP professionals for jobs?
Date: Mon, 18 Dec 2000 08:26:08 GMT
Los Angeles
12/17/00
Dear Members,
I'm writing to you to request your advice on a problem I'm having.
I am a Technical Recruiter here in Los Angeles, specializing in IT Candidate
delivery.
My problem is, I've got this Hot company who need talent in the digital
wireless arena, which is way out of my normal focus and I'm having a hard
time finding the right candidates (See below.)
I saw your contact info on the Internet and I wonder if you could tell me
where I have to look to find these people? Do you know the professional
associations, user groups, newsgroups or societies they might subscribe to?
Any advice to point my nose in the right direction would be most
appreciated.
Maybe you might be open to referring (or forwarding this email) to any of
your friends who might be interested in these opportunities.
Of course, If YOU are interested, that would be GREAT!
Thanks for your time and help
Regards
Prem Hamilton
818 882 3999
**********************************
Sr. DSP Programmer. (Digital Wireless)
The company is a pre IPO venture backed wireless Technology Company here in
sunny Los Angeles.
Developing the first wireless IP Telephony networks, they are well funded by
a blue chip family of investors and have a $2 million order backlog. They
manufacture secure, all digital, Internet-linked ESMR trunked and
non-trunked dispatch radio equipment. The Company's completely digital
product family, the DigiStar NetworkT, operates in the 140-700 MHz bands, in
6.25, 12.5 and 25 kHz spaced channels at 4.8 kbps, 9.6 kbps and 19.2 kbps
respectively. The DigiStar NetworkT provides secure conversation and
seamless network coverage for business, government, military users and more.
If you know your way around DSP coding for next generation wireless
applications, and you are ready to look at a terrific opportunity that
offers a very competitive salary and benefits package, profit sharing and
stock options. and the chance to be an important part of a highly successful
and motivated team.
Please submit your letter of interest and resume to: [EMAIL PROTECTED]
Relocation assistance possible for right candidate.
US Citizens or Permanent Residents only please.
**********************************************************
Submit your letter of interest and resume ASAP to: [EMAIL PROTECTED]
Please reference job title in subject line. Thanks.
-I will call you back immediately!
Call: Sourcing Solutions in Los Angeles at 818 882 3999
Ask for Prem Hamilton
**********************************************************
Engineering Positions in Los Angeles
Senior RF Designer
DWC is developing a next generation software defined wireless phone, and
requires a senior RF engineer to lead development of several products. If
you live and breathe RF at the component level, we want you! Minimum
educational requirement is a BSEE in a related discipline with appropriate
experience.
RF Engineers and Technicians
If you have circuit level experience with VHF and UHF RF designs, several
positions are available in our RF team.
Bluetooth/GPS Engineer
We're looking for an EE to lead our Bluetooth and embedded GPS program.
While RF experience would be a plus, solid digital design experience is the
primary prerequisite.
Digital Designer
If you want to tackle very low power processor design for portable
equipment, and have appropriate EE experience, we're looking for a team
leader to supervise our digital designs.
Senior PCB Designer
PCB designer with five or more year's experience designing analog and
digital multi-layer fine pitched PCBs.
Mechanical Designer
If you have demonstrable experience in the design of molded plastic and die
cast enclosures, and would like to participate in the development of the
next generation of cell phones, send us your resume. 3D experience with ProE
a plus, and AutoCad fluency a must.
Senior DSP Programmer
If you know your way around DSP coding for wireless products, we need a team
leader to develop next generation high feature wireless products.
Software Engineer
Develop real time applications, device drivers, and utilities in C/C++,
Unix, QNX, and TCP/IP.
Applications Designer
Develop end-user application/interface code, common database
infrastructures, in visual languages (C/C++, VB, VFoxpro, Power Builder),
ODBC connectivity, SQL, amd ActiveX controls.
Internet Protocol Expert
If you have deep experience with IP, you could help further develop the
company's worldwide IP based network infrastructure, protocols and
applications.
Microcontroller Engineer
Appropriately experienced programmer fluent in Motorola microcontroller
assembly language applications.
Management Positions in Los Angeles
COO Manufacturing
The company is looking for a senior manager with extensive experience in
electronic manufacturing to direct its production, procurement and
outsourcing activities.
Controller
We're seeking an experienced controller comfortable with a technology driven
company, and capable of initiating enterprise wide accounting systems,
including overseas subsidiaries.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Result of an old thread?
Date: Mon, 18 Dec 2000 09:54:06 +0100
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> > Bryan Olson wrote:
> > > Mok-Kong Shen wrote:
> > > > And would such a B' be invertible?
> > >
> > > Some are. An invertible solution works in Best's solution
> > > for S. We could of course solve for S using a system of
> > > linear equations without worrying about choosing an
> > > invertible solution for B.
> >
> > Just knowing some are invertible would solve the problem,
> > I suppose, if one has to try extremely long.
>
> What are you talking about?
I meant what do you do if you get a B' and found that it
is not invertible. You'll try the next candidate, do you?
An what if that processes fails again and again, analogous
to trying to factor a product of two primes through
random trials?
>
> > I don't
> > understand your last sentence. Which system do you mean
> > that you want to solve?
>
> You see anything non-linear in the scheme? Is there enough
> information to determine S? Does that tell you anything?
Yes for the first question. No for the other questions.
It is the singularity of S, not any non-linearity, that
causes troubles. Anyway I can't yet determine S. If you
see a systematic way, then please kindly illustrate
with a concrete example with matrices of size, say, 3, so
that your idea becomes clear.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Use of multiplexing
Date: Mon, 18 Dec 2000 09:54:00 +0100
Simon Best schrieb:
>
> Mok-Kong Shen wrote:
> >
> > Multiplexing is a rather old topic in CS. In the crypto
> > context, it is also well-known (see spread spectrum, CDMA).
> > I like to consider the issue presently, however, purely
> > at the application level, i.e. whether a normal user, who
> > does encryptions as usual, can profitably apply multiplxing
> > techniques of his own.
>
> Is this a user level thing, then?
>
> > In plenty of situations one does not send occassionally
> > single messages. Between two distant officies of a
> > commercial firm, for example, a substantial amount of
> > communications, usually of different security levels,
> > occur.
>
> So it's not at the user level, but at a network level. How about
> encrypted IP over IP? Are you suggesting network packets get
> multiplexed and then split into 'perpendicular' network packets? What
> if network packets are infrequent? What if a whole load of network
> packets arrive at the gateway but which all belong to the same
> transmitted file?
>
> > It is thus feasible to multiplex the messages,
> > i.e. intermingling them in some secret (either fixed or
> > dynamically varying) way that is unknown to the opponent,
> > thus rendering his analysis job difficult. There will
> > certainly be some appreciable cost/work involved for
> > the partners doing multiplexing, but the resulting
> > difficulty caused to the opponent could under circumstances
> > justify that, I believe. I wonder thus whether such
> > multiplexing has not already been successfully employed in
> > practice.
> >
> > We note that multiplexing can be done at two different
> > levels, (intermingling of plaintexts and of ciphertexts),
> > and also at different granularity (word/byte/bit).
> >
>
> It's an interesting idea, but there are those issues I asked about that
> would need to be addressed, depending on the level at which such a
> cryptosystem would exist.
You central question was whether my suggestion is at
the user level. The answer is, as stated in the post,
yes. The user (or the message centre of a firm) collects
a number of messages and can e.g. mix them, say in bytes,
then encrypt the whole and send that. The receiver
decrypts and de-mixes.
M. K. Shen
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Mon, 18 Dec 2000 09:59:49 +0100
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>Francois Grieu wrote:
>> There is a problem with this approach. As a proof of concept,
>> assume the play and replay program are genuinely deterministic
>> and running the same code on identical brand CPU, except for
>> clock speed, and a human changes the clock speed of the play
>> machine while running. The programs sends queries every say
>> 1 million instructions. If the adversary has played after say
>> 10 queries, the program plays defensively, else it plays
>> offensively. A human looks at the game, and when it thinks the
>> program has a good position, slows it down. It will start
>> to defend (sensing the adversary is fast). The replay program
>> will automatically be kept in sync by the log.
> This is similar to the idea of using packet timing as a side channel.
Agreed entirely. We should find a way to close it, as even a small
side channel is very useful. Actually I think I have a technique,
wait a bit.
> > Besides, there is no way you'll prevent the play program from
> > beeing non-deterministic and reading wall clock time.
>
> Sure you can. If the program is deterministic, it will play identically
> on the replay machine, and if it is nondeterministic, it will play
> differently.
I meant that the play program can use wall clock time to decide
the period of the poll_opponent its sends from the state of the
caps-lock key, rather than really slow down the CPU rate. The
program can be kept in sync using your protocol:
> poll_opponent, get_opponents_move, and send_move_to_opponent are
> in a referree supplied dll. On the game machine, these perform
> network io, and write protocol-specified infomation to a log file
> -- specificly, how many calls to poll_opponent were made before
> get_opponents_move and what move was made. On the replay machine,
> poll_opponent returns falls N times, where N was read from the log,
> then returns the opponents move from the log, then compares the
> resultant move with the one stored in the log.
Say the poll period of the play program is 0.5 or 2 second depending
on the caps-lock key, and that it is the sole influence of wall
clock time. In this way the play program is not deprived of CPU time.
The replay program sends queries as a deterministic function
of its progress, say simply spaced by some suitable wait loop
resembling 1 second, and count how much queries it sends before
getting a yes answer.
The trick is that as long as only the number of poll_opponent
queries before a positive answer influence the play of both programs,
the two programs are kept in sync despite the variable poll rate.
Both the play and replay program sense the same difference in the
number of queries to poll_opponent before the opponent responds,
and can play accordingly. For a refined strategy see [*]
> As I said, the look-at-wall-clock cheat results in a game that
> can't be reproduced by the replay computer
No ! And it does not even prevent from working while the opponent
does. And it is a nice side channel.
Fortunately, I hope this side channel can be closed by replacing
the periodical poll_opponent (with period chosen by the player)
by a periodical opponent_has_not_moved_yet message (with agreed
period controlled by the referee, or the adversary). Drawback is
that the play program must either
- wait for the opponent_has_not_moved_yet call to advance its work,
and in fact slow down to not go ahead too fast.
- or be able to back-up.
On the replay side, there is no such issue: the replay program
can receive the move of the opponent right after its own move,
together with the number of opponent_has_not_moved_yet messages.
Still, the opponent could try to influence the speed of its
adversary in some means, but that is a much less practical side
channel. I believe this side channel is closed entirely if the
opponent_has_not_moved_yet message is timed not in wall clock
time, but in instruction executed by the opponent.
Francois Grieu
[*] I modify the strategy into a practical and hard to detect
one with two additional steps.
First, the cheater refines the logic of its programs, using what
I call a "spread-spectrum" technique to make the side channel more
robust and less apparent (but also loosing some capacity).
Call Qj the sensed number of queries for the adversary to answer,
exactly identical on both play and replay program by the very
referee process. Let Rj be a fixed pseudo-random sequence.
At each move, when the program hesitates between two moves
of nearly equal value, one for attack, one for defense, it
decides which to play according to Sign(Qj-Q(j-1)) XOR Rj.
This logic is the same in the play and replay programs, so
they will allways play the same.
The play program selects a poll period of 0.95 or 1.05 second
depending on State_of_the_caps_lock_key XOR Rj.
Now of course, if the adversary plays at a mostly regular
pace, Qj is corelated to the poll period, so the
State_of_the_caps_lock_key tends to influence the play style,
with Rj acting as a confuser for the referee. The programs
will never make a worse blunder than they would by choosing
randomly between the attack and defend moves, which can be
equal for obvious moves.
Second, the cheater conceals its variable poll period into
noise, making it a gaussian with mean 0.95 or 1.05
second and standard deviation 0.2 second. No change is
needed in the replay program. The capacity of the side
channel is not much reduced, since the gaussian noise will
mostly cancel over the period of a move.
NB1: the reliability and thus usefulness of the side channel
can be inscreased markedly if Sign(Qj-Q(j-1)) is replaced by
Sign(Qj-F(previous_Qjs, previous_game_states)) with F a predictive
function trying to compensate for variation in the adversary
response time caused by obviousness of the situation; since
F is identical on both sides, the programs are still in sync
NB2: Rj can be made a deterministic pseudo-random function of
previous_Qjs and previous_game_states with the advantage that
the referee is even more confused, and has a harder job to
corelate its observations of the play program across several
games, to detect it is cheating.
------------------------------
** 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
******************************
