Cryptography-Digest Digest #254, Volume #11 Sat, 4 Mar 00 21:13:01 EST
Contents:
Re: Storing phone numbers safely for later comparison - somewhat newbie (wtshaw)
Re: On jamming interception networks (Jerry Coffin)
Re: Best language for encryption?? (Bryan Olson)
Re: Random bit generators (Guy Macon)
Re: Random bit generators ("Joseph Ashwood")
Re: 'Free' services with tokens/puzzles ("Joseph Ashwood")
Re: very tiny algorithm - any better than XOR? (David Hopwood)
Re: brute force attack on a 128 bit SSL key? (Jerry Coffin)
Re: New US export regs (was Re: Crypto.Com, Inc.) (David Hopwood)
Re: CLSID and Security (David Hopwood)
Re: very tiny algorithm - any better than XOR? (Andru Luvisi)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Storing phone numbers safely for later comparison - somewhat newbie
Date: Sat, 04 Mar 2000 16:41:49 -0600
In article <[EMAIL PROTECTED]>, "Lance" <[EMAIL PROTECTED]> wrote:
>
> Specifically, I'm working on an application and for fraud control
> reasons I need to maintain a database of abusive social security numbers. I
> don't need to search these
> in the future (in plaintext anyway) - only know wether to reject a "service"
> based on some metrics.
>
> For security/privacy reasons I don't want to store them in plaintext, but it
> would seem
> that hashing them wouldn't be terribly secure given the rather short amount
> of time it
> could take to precompute all the combinations of SSNs.
>
> Obviously I could lengthen the cleartext by pre/appending constants, but
> that has
> it's own caeveats.
>
> What are my other options? Keep in mind that I do need the hashing to be
> relatively
> quick ( < 0.5 seconds per compare including SQL query time )
>
> I'm sure there are a few solutions that will work, so any help is
> appreciated.
>
Most of the options are bad, but I can tell you about a method that will
do exactly what you want, no joke. ROT13 to get my email, and sent me an
email.
--
Imagine an internet on an up and up basis, where there are no subversive techniques to
rob a person of their privacy or computer
functionality, no hidden schemes used to defraud anyone. :>)
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Sat, 4 Mar 2000 16:28:04 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Simply saying your opponents are wrong is something any kid could
> do in their talks. Clearly giving detailed and concrete reasons why
> your opponents are wrong is what adult persons engaging in scientific
> discussions do.
I've already pointed out why I think you're wrong, but since you
persist in the argument anyway, perhaps it's reasonable to point out
a few other indications.
IIRC, at one point you said you were interested less in the NSA per
se, than the intelligence community in general. I personally believe
they not only do very little covert surveillance, but in fact don't
even bother collecting and processing huge amounts of data that are
completely legally and publicly available.
Just for example, it's trivial for somebody with no credentials or
anything on that order to get onto Excite, Alta Vista, Google, or
whatever search engine they prefer, and find literally hundreds of
web sites with all manner of threats that, if considered credible,
are actually illegal ("assault" is a credible threat of violence, and
does NOT require that one actually harm or even attempt to harm
anybody; likewise, there are laws against doing things like
threatening to kill people, and again, no actual attempt at killing
anybody is needed for the law to have been broken).
Just for one really obvious example, the people who murdered, maimed,
etc., school kids at Columbine last year had a web site up that
pretty much told the world what they planned to do. People had even
pointed it out to the Police, and they completely ignored it.
To me it seems downright ridiculous to assert that on one hand they
ignore all sorts of information that they could obtain VERY easily
and completely legally, but go to the trouble and risk of obtaining
similar information in a manner that's illegal and MUCH more
difficult to boot.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Sat, 04 Mar 2000 23:25:46 GMT
wtshaw wrote:
[...]
> Good algorithms are not that hard to fine, and good
> immplementations not that hard to write if you think
> top-down and use the tools that get better every day.
> The same goes for security matters in gneral. I am
> learning why so many think otherwise; what a shame.
> The unwelcomed result of the prevalence of how things
> are is that many live to cultivate problems rather
> than using adequate solutions.
A programmer's code speaks for itself.
On 03 Jan 2000 in sci.crypt, wtshaw wrote:
| Here is a demo function that converts come
| characters to trits. The code characters list
| can be easily extended to whatever you care to
| include.
[...]
| WINDOW #1,,(0,0)-(445,294), _dialogPlain:CALL HIDECURSOR:PRINT
| REM written to accomodate a growing list of characters
| PRINT "This program converts strings of up to 70 allowed characters to
trits." PRINT "Enter no
| characters to quit.":PRINT
| "begin":LINE INPUT a$:IF a$="" THEN END
| L=LEN(a$):IF L>70 THEN a$=LEFT$(a$,70)
| a$=UCASE$(a$):PRINT:PRINT a$:PRINT:out$="":trits=0
| FOR j=1 TO L:c=0:x$=MID$(a$,j,1):temp$=""'get character
| IF x$="A" THEN temp$="12"
| IF x$="B" THEN temp$="2111"
| IF x$="C" THEN temp$="2121"
| IF x$="D" THEN temp$="211"
| IF x$="E" THEN temp$="1"
| IF x$="F" THEN temp$="1121"
| IF x$="G" THEN temp$="221"
| IF x$="H" THEN temp$="1111"
| IF x$="I" THEN temp$="11"
| IF x$="J" THEN temp$="1222"
| IF x$="K" THEN temp$="212"
| IF x$="L" THEN temp$="1211"
| IF x$="M" THEN temp$="22"
| IF x$="N" THEN temp$="21"
| IF x$="O" THEN temp$="222"
| IF x$="P" THEN temp$="1221"
| IF x$="Q" THEN temp$="2212"
| IF x$="R" THEN temp$="121"
| IF x$="S" THEN temp$="111"
| IF x$="T" THEN temp$="2"
| IF x$="U" THEN temp$="112"
| IF x$="V" THEN temp$="1112"
| IF x$="W" THEN temp$="122"
| IF x$="X" THEN temp$="2112"
| IF x$="Y" THEN temp$="2122"
| IF x$="Z" THEN temp$="2211"
| IF x$="/" THEN temp$="21121"
| IF x$="." THEN temp$="121212"
| IF x$="," THEN temp$="221122"
| IF x$="?" THEN temp$="112211"
| "skip":out$=out$+temp$+"0"
| T=LEN(out$):IF T>40 THEN trits=trits+T:PRINT out$:out$="" NEXT
j:T=LEN(out$):IF T>0 THEN PRINT
| out$
| trits=trits+T:T$=STR$(trits):L$=STR$(L):PRINT
| PRINT T$;" trits from";L$;" characters"'display result GOTO "begin"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random bit generators
Date: 04 Mar 2000 18:59:02 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
([EMAIL PROTECTED]) wrote:
>I do not think I am XORing anything.
I never said that you were.
>I am pseudorandomly selecting bits from one or the other.
I understand that. I am just bringing up the question of how this
method is better or worse than the XOR method so that I may learn
more about the concept.
Lets take an extreme example.
Assume that we both have three sources of what we beilieve are
random bits. You use the "chooser" method to arrive at a single
bit stream. I XOR two of the bitstreams, then XOR the result
with the third.
Unknown to us, an attacker has partially compromised our security,
and can predict one of the "random" bitstreams and can choose the
other. Assume the third is true random. With my XOR systyem, the
output is also true random. With your chooser method, the output
is not true random.
I picked this example to make XOR look good. I am in no way implying
that XOR is better in more likely situations. As I said, I am just
trying to get a handle on the advantages and disadvantages of what
you are describing.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Random bit generators
Date: Sat, 4 Mar 2000 16:33:35 -0000
To me, different uses benefit from having different
statements of the algorithm.
Taking a more concrete exmaple to make the point. Let's take
DES. It can conceptually be pictured as z=DES(x,y). For the
sake of space we express it algorithmically, but there does
exist a simple function (like we all saw in Algebra), given
that expanded (and more optimal for analysis) function more
headway could probably be made in certain types of analysis
(in particular algebraic solving). There is also an
expression that is useful for differential, one for
bit-slicing, different chaining modes, etc.
Looking at it, I was wrong, I should have stated that your
speed _may_ not be optimal. There is probably another
statement of the algorithm that is at least as fast.
Joe
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> : <[EMAIL PROTECTED]> wrote:
> :> Joseph Ashwood wrote:
>
> [combining RNGs]
>
> :> > Suggestions similar to this come up quite often. And
the
> :> > only conclusion that can be derived from it without
> :> > knowing the functions involved is to say that there
exists an
> :> > optimal function f() that is equivalent to your
> :> > suggestion, and that your security depends solely on
the
> :> > security of that function. OTOH your speed does not,
your
> :> > speed will not be optimal. I suggest that if you are
truly
> :> > interested in the security of such a method you find
the
> :> > function f() so that it can be accurately reviewed,
by you
> :> > and others.
>
> :> What exactly are you replying to?
> :
> : I was replying to what you wrote.
> : Take the output of three prngs and use the 3rd one to
choose
> : from the other 2.
>
> I'm not sure I followed your comments, either.
>
> Using three congruental generators and using one to choose
between
> the output of the other two may be the simplest way to
express the
> function f() you describe.
>
> You don't present any reason /why/ you think this will be
slower than
> "the optimal function".
>
> I suspect - in the case where the three congruential
generators in
> question have relatively prime periods - it will *be* the
optimal
> function, in terms of concise expression/memory
usage/speed of
> operation, when implemented on most systems.
> --
> __________
> |im |yler The Mandala Centre http://www.mandala.co.uk/
[EMAIL PROTECTED]
>
> Standards aren't.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: 'Free' services with tokens/puzzles
Date: Sat, 4 Mar 2000 16:57:37 -0000
There are of course many possibilities to tip the odds in
your favor. I am assuming that you are using this to compute
a large simultaneous problem (like brute-forcing a cipher).
Needed: Source of assumed randomness (it is only necessary
that the clients are not able to compute the values). A
trusted network for server(s) and absolutely trusted
client(s).
The servers need to distribute real blocks of compute to
both the trusted an untrusted clients, in such a way that
the untrusted clients can not compute whether they are
receiving a challenge block or a real block. Both the
trusted and untrusted clients compute the blocks, and inform
the server if a real solution was found. Both the trusted
and untrusted clients send the entire partial solution to
the servers. Store some of the outputs of the trusted
clients, you don't need all of them.
The servers "Randomly" insert known solution blocks into the
stream to the untrusted clients. You can easily know which
blocks were challenge blocks, and ignore the others. If you
receive a known challenge block back compare it to the
output of the trusted clients, if the output differs, you
obviously have a rouge client.
The main issue is that instead of simply being able to trust
the clients, and go based on their yes/no answer, you are
requesting a large amount of data be returned. This could be
altered so that you pass a large number of blocks to the
client at once, the trusted clients return all information,
the untrusted clients only return the kth value (which you
could randomly dictate). Either way, it would become
extremely difficult for a rogue client to go undetected for
a significant amount of time.
Joe
------------------------------
Date: Sun, 05 Mar 2000 00:53:19 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: very tiny algorithm - any better than XOR?
=====BEGIN PGP SIGNED MESSAGE=====
Carl Byington wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[...]
> >How much data space do you have? I would seriously recommend against
> >trying to create a new algorithm, but it may be possible to use a
> >smaller variant of an already analysed algorithm.
>
> The processor has 512 bytes of ram, but there are a lot of other demands
> on that. We can have 20 to 30 bytes of ram for the encryption, 64 bytes
> is not possible.
and in another post:
> Each device has the cpu, 512 bytes of ram, and 1MB of eeprom. [...]
> Since the key(s) are stored in eeprom, it does not count against the
> 50 byte code space restriction. All the instructions on this processor
> are either 16 or 32 bits long, so we have 25 instructions to work with.
I assume that access to the EEPROM is slower than to the RAM, that it
has a limited number of writes before expected failure, and that it may
have to be erased/rewritten in blocks, rather than a byte or word at a time.
The 20-30 byte RAM limitation is a more severe constraint than the 50 byte
code size, and I'm not aware of any well-respected modern ciphers that
would satisfy it directly. However, how about storing precomputed keystream
from a stream cipher in the EEPROM, as if it were a one-time pad? As
content is decrypted, it replaces the corresponding part of the keystream.
Decryption only requires the EEPROM to be read at the same rate as the
encrypted content becomes available, so it should be reasonably fast.
While you're generating the stream (i.e. initially, and when the memory
becomes "full", so that space for deleted data needs to be recovered),
store any temporary data in the EEPROM if necessary, and load it back
afterwards. That way you have the whole 512 bytes of RAM to play with
for the encryption itself, and can use standard RC4 as the stream cipher
(for example, 256 bytes of table space plus some space for buffering, if
necessary).
Of course this assumes that it is possible to put the device into a mode
where it is not doing anything else, for long enough to precompute
sufficient keystream and write it to EEPROM. (An alternative would be to
make this part of the process of deleting stored content.)
To reduce code size, I would recommend storing the RC4 state (i.e. S-box
array and i, j) in the EEPROM, rather than the original key. Make sure
to start with a state that it is actually the expansion of a key using
the normal key schedule, because RC4 has some bad states otherwise.
Note that it is essential not to encrypt using a given piece of keystream
more than once (so it would not be secure for the decryptor just to tell
the encryptor what the current stream position is, for example). If there
is only one entity encrypting content, all it needs to do is store the
current RC4 state for each user. If there is more than one entity encrypting
content, this approach probably won't work as it stands.
> >For example, RC4 can certainly be implemented in 50 bytes of code space
> >(probably much less), so the only potential problem is its RAM requirement.
[...]
> >Note that, as for any stream cipher, you should not use the same key for
> >more than one message, without adding a random salt.
>
> Thanks for the pointer to RC4. However, the system design at this time
> implies that we will use the same key for all the content owned by the
> same entity (person, family, whatever). It will not be unusual for one
> key to protect a few megabytes of content.
That's not a problem in itself, provided you don't use any part of the
keystream more than once.
> I presume that we need some secure mechanism of passing the random salt
> to the decryptor.
You don't really need salt for the approach suggested above.
> We don't have 64 bytes of ram. From your comments above I take it you
> would not use 5-bit RC4?
IIRC, up to 4-bit RC4 has been broken, so no, I wouldn't.
If you need more detailed design advice or programming, I'd be happy to act
as a consultant (under NDA if necessary).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMGvqzkCAxeYt5gVAQEATgf8D7VYPQteHps7+A+h2aYaO/H+ZzFDm1zT
a5b6NIy+hTzEUZC8uQ3VtUP/9R9gCOLiEyf78Tz7kaWtknI0Y/jAbnRKVhh5EfGu
AnO2kmAUhPMhK+hA48ZYlOSgZ4yV78Er+Da6+AAjT2aSHM3P1pQ6oojEO213eAdZ
KCj7oKVx8PcVQjEiuDG5VRoXaWXTutgtImsccrure337QZ3FNcyltZTNdOGFNd83
zNAuQp3GB4CHslBC+0II28eJ6FBqTYUsxPVyTjzBlmeptcyQvUPRearYynw2NEQk
rXKHoBayowvI8UA/3Qx8WeZY5T7WoqNKjQ9Wzb94vO1LUgQDt/acFw==
=eYvw
=====END PGP SIGNATURE=====
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: brute force attack on a 128 bit SSL key?
Date: Sat, 4 Mar 2000 18:12:37 -0700
In article <89p4v5$umc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > In article <89jrge$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] says...
>
> <snip>
>
> > > That's the problem. You remember what
> > > "assume" represents, right?
> > >
> > > For example, wasn't it 30 years ago that
> > > some "expert" said it would take 40 quadrillion
> > > years (40,000,000,000,000,000 years) to break
> > > DES.
> >
> > I doubt it -- the small key size of DES has been a subject of
> > discussion (and considerable complaint) since before the ink dried on
> > the proposal to use only 56 bits.
> >
> > To put things in mathematical terms, 40 quadrillion years would mean
> > testing just over 18,000 keys per year. That's about 49 keys a day,
> > or just over 2 keys an hour. I suspect somebody who was careful
> > could encode one block with DES _almost_ that fast by hand. Even the
> > simplest hardware (e.g. the Eniac) could certainly test keys a LOT
> > faster than that, and hardware that was common when DES was invented
> > was a LOT faster.
> >
> > > Hmmm. Was he right? I don't think so.
> >
> > If anybody really said that, they were clearly wrong. I seriously
> > doubt anybody did, because if anybody did so, s/he was obviously a
> > LONG ways from being an expert in much of anything, down to and
> > including arithmetic on the level I seem to recall learning before I
> > was a teenager.
>
> Can't anyone get their facts right????
Hopefully a few people can...
> (1) The quote was about RSA-129, not DES.
_A_ statement was made about RSA-129. It's _likely_ that it's the
same statement which the original poster was attempting to refer, but
there's no real guarantee of that.
> (2) RSA-129 means 129 digits (not bits as claimed in another post)
> (3) The quote, believe it or not, came from Ron Rivest. [sarcasm on]
> Obviously he is a long way from being an expert on anything.
There's no need to be sarcastic -- I _specifically_ said that I
doubted the statement was made about DES, but IF it was, then the
peson who made the comment was clearly wrong, and hadn't done simple
arithmetic correctly.
I suppose, in fairness, I should admit that it's possible to have
undeniable expertise in some areas, while having little or none in
others. Most people I've met who I believe are truly experts are
generally quite careful when making comments outside of their field,
so I'd still be very surprised if an expert at much of anything would
have made such a grossly incorrect statement about DES.
> Some has already posted approximately correct arithmetic about
> breaking a 128-bit symmetric cipher by brute force.
I've seen only two in this thread: one I posted, and one based on
thermodynamics that was apparently attempting to explore the bare
minimum it could ever take in theory. I'm not entirely sure I agree
with the premises of the latter; Doug Gwyn is convinced that it's a
misapplication of the laws of thermodynamics, and I'm certainly not
prepared to argue thermodynamics in any case. Ultimately, the answer
remains the same in any case: you can't plan on breaking a cipher
using a 128-bit key by exhausting the key space. A practical attack
absolutely _requires_ that you find some method that reduces the
search by quite a large factor.
> Despite this,
> we have people ranting about differential and linear cryptanalysis
> when the question was about breaking 128-bit SSL. Differential and
> linear analysis while being nice theoretical tools are USELESS in
> practice. Take DES. Differential analysis requires getting your
> adversary to provide a ridiculously large number of plaintext/ciphertext
> pairs. Exactly how are you going to get him to do that? And where
> do you propose to store 2^46 message pairs?
There's no question (at least in my mind) that they're utterly
useless against DES or quite a few other good algorithms. That
doesn't mean they're useless in general though: some older algorithms
that look reasonably secure against many (if not most) earlier
attacks require collection of FAR fewer plaintext/ciphertext pairs
than DES.
Just for example, the 8-round version of FEAL was broken using only
10,000 known-plaintext/ciphertext pairs. That requires getting only
ONE decent-sized file of known content, and the storage involved is
absolutely trivial.
As far as exploiting it goes: that depends a great deal on the design
of the overall system. Just for the sake of argument, assume a
company used a VPN that used FEAL-8 for its encryption. You want to
break that encryption. You get somebody a job as a janitor at the
target company, and sometime when somebody leaves a machine
unattended, they simply copy something like Microsoft Word from one
machine to the other, overwriting the existing copy on the target
machine. Since the file already existed on the second machine, it's
not particularly obvious that anything's happened at all. I'm pretty
sure we can depend on any MS product being large enough to provide
more than 10,000 blocks of ciphertext, so even in the worst case,
we're left to find which of a half-dozen or so minor revisions of
Word was involved. I haven't tried to figure things up exactly, but
it seems likely to me that you'd probably have broken the encryption
before your janitor goes home for the night...
> *Thankfully* there are a few people who can do arithmetic.
> *Unfortunately*, too many people (who clearly have no clue what they
> are talking about) have posted misinformation on this topic.
The question is: On WHICH topic? How long it takes to break DES, how
long it takes to break RSA-129, or how long it takes to exhaust a
128-bit key-space?
Of course, those are three completely different questions with three
completely different answers. If I had to give thumbnail summaries,
I'd say the first two are possible but quite difficult, while the
latter is currently impossible and we don't even have a solid idea of
an approach toward making it possible.
Obviously that's simplifying a LOT, but if, for example, I had to
explain it to somebody who wasn't (and didn't want to be) technical,
that would be reasonably accurate without getting mired in detail
about which they didn't care anyway.
Of course, this is a newsgroup that's supposed to be more detailed,
technical and (at least theoretically) scientific, which is why I
originally published a much more detailed summary of what it would
take to search a 128-bit key-space...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
Date: Sat, 04 Mar 2000 21:03:27 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: New US export regs (was Re: Crypto.Com, Inc.)
=====BEGIN PGP SIGNED MESSAGE=====
wtshaw wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> > You don't need them to send email to you:
>
> If yo are requested to send them something, it is comforting to know that
> a communication was actually received. I guess I remember the chronic
> loss of AOL mail experienced here long ago. But, anything can happen
> enroute.
Yes, but since the regulations explicitly say that sending them an email
is sufficient (for the TSU license exception), that's their problem, not
yours.
> Figure that if they say they did not receive it, they have no reason to
> complain. Perhaps the dog ate it, I forgot to send it, I thought I sent
> it, or my program did not work right, or they just lost it themselves.
Exactly :-)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMF57zkCAxeYt5gVAQFD7Qf/YGaX/7ysJ3cGUBfDBnUQh9PiwHRUfkpk
IbqmcHN9eVzZAHzW5gnlARM8bWHTA39isxKPtCvAq81UjR7AT9+sZwAnmoQ8w5o7
+4onwyh2radk4yc6Mo9D3HDiDJ6n0Uqc+knrZ/UONPDVe0qsl/vzRNbS9Hnm7EQ9
j7nwEQkOy2hv8YOUiL8HD6OqDQNRvdQ4/rXSMeQXYoNLUcWJhPipOL53TGfzkbxV
pdehKKQcTABRjieWCos9Ey0P/0zjNif2RaSgsZ5gVrTycru5VBOfnzW/2F7stHhM
Y7Nc/6Z3p0AmsM7Ww6tJb/etQMq3RewldsM7VKidTgoCtjh2HPnGyA==
=JKBs
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 04 Mar 2000 23:25:47 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: CLSID and Security
=====BEGIN PGP SIGNED MESSAGE=====
"John E. Kuslich" wrote:
> I was reading the Microsoft documentation on COM objects and how CLSID's
> are used to provide, with almost absolute certainty, a uniquely identifying
> number. This number is used to identify interfaces for COM objects across
> any arbitrary boundary.
>
> They then go on to say that these CLSID's are not linked to the ethernet
> MAC address for security reasons.
Where do they say that? It's not correct: CoCreateGUID does use the MAC
address when it is available.
(In general, all of Microsoft's documentation has to be taken with a
healthy degree of skepticism, especially with regard to security. In
particular, they often document what somebody thought should happen,
rather than what somebody else implemented.)
> Well, when I compute a CLSID using the CoCreateGUID from the Windows API, I
> find that the MAC address of the GUID so created is laying right there in
> the last few bytes of the GUID.
>
> What am I missing here.
>
> I can surely see why the MAC address could be a security risk in some
> situations.
You're not missing anything, AFAICS.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMGbFDkCAxeYt5gVAQG1Bgf+MO9uiGcGUSSFviTaUt/DuF7cAlsETwX5
EwxiSljxyFpUKiOf8phPYFdhwM4WthQl+KvfBedFZXednvEGMV0iHfc2YHJ/G3Oo
yFSCMQd3Zx54KI8zNZU+J1Ef4dWCJzJ41Zw9AvOSXtiU+HvDHGWOWnhhFofsRDgV
NOPw/7nlzkQE3RTleznFUhHO7fry8POCDONfadtHKj1kEENlJlBPN3NTEWWlv1Fw
80PFAyfUGAceCiXhsOBIQbMTe9EhqDDkx7mHGBuPw9NKwpg/ka5qUictRX6Az5Ql
PVEZaCByr2Uqayug2GFaa0eFjHMMIdnrJXLE6+h7FIbeBrdsweTHSg==
=Sle2
=====END PGP SIGNATURE=====
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: very tiny algorithm - any better than XOR?
Date: 04 Mar 2000 17:30:33 -0800
[EMAIL PROTECTED] (Carl Byington) writes:
[snip]
> I need to do some more reading on stream ciphers. It seems to me that
> we use the key to setup the initial state of the keystream generator.
> That generator then produces a bit stream that we xor with the data
> to form the cipher text. Of course, we should not use the same key with
> multiple texts in this scheme, which is where I get confused. How do
> we solve the problem of needing a different key for each message?
[snip]
Usually with an Inivialization Vector, or IV.
For example, if you were using a block cipher in OFB mode,
Output_0 = IV
Output_i = E_k(Output_{i-1})
Ciphertext_i = Plaintext_i XOR Output_i (for i >= 1)
Sometimes, you send the IV before the ciphertext. It doesn't have to
be secret, it just has to be different with *every* message so that
the output is different each time.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
** 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
******************************
