Cryptography-Digest Digest #718, Volume #12 Tue, 19 Sep 00 15:13:00 EDT
Contents:
Re: Optimization for speed question. ("Dann Corbit")
Re: Stream cipher (Albert Yang)
Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an (Mok-Kong Shen)
Proper way to intro a new algorithm to sci.crypt? (Albert Yang)
Re: Dangers of using same public key for encryption and signatures? (Mike Rosing)
Re: Double Encryption Illegal? (WARNING: GERMAN) (Mok-Kong Shen)
Re: Algebra, or are all block ciphers in trouble? ([EMAIL PROTECTED])
Re: Algebra, or are all block ciphers in trouble? ([EMAIL PROTECTED])
Re: Proper way to intro a new algorithm to sci.crypt? ("Paul Pires")
Maximal security for a resources-limited microcontroller ("Sagie")
Re: Chosen and known attacks - are they possible ?? (Bryan Olson)
Re: Software patents are evil. (Ichinin)
Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption (Terry Ritter)
Re: A conjecture - thoughts? (John Rickard)
Re: Maximal security for a resources-limited microcontroller (Paul Rubin)
Re: ExCSS Source Code (Eric Lee Green)
Figures of Merit for Crypto=Systems (dbf)
Re: BUG In CryptLib3 - by Peter Gutmann. Is there a fix? - Additional info ("Michael
Scott")
Re: CDMA tracking (was Re: GSM tracking) ("Sagie")
Re: Music Industry wants hacking information for cheap ("Sagie")
----------------------------------------------------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Optimization for speed question.
Date: Tue, 19 Sep 2000 10:03:57 -0700
"Tor Rustad" <[EMAIL PROTECTED]> wrote in message
news:izJx5.3731$[EMAIL PROTECTED]...
[snip]
> > Miller-Rabin does not answer the question. Period.
>
> Neither does a provable algorithm, when implemented by humans and run on a
> computer in the real world. Period.
>
> I don't even have to use quantum mechanics to point to the error
sources...
What drivel. By the same token, no theorem can be proven by people using
pen and paper either, because it is possible for mistakes to exist.
The Nth Mersenne Prime is found by computer for all large N. And everyone
accepts them because it is verifiable. The same thing goes for prime
proving with carefully debugged programs.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Stream cipher
Date: Tue, 19 Sep 2000 17:19:49 GMT
I have finished up a stream cipher called "Smallfoot", it was designed
for implementation in hardware, and as the namesake, it was designed
with the smallest footprint possible in mind. Total memory usage count:
70 bytes for an implementation with a 256 bit key. The thing is
blazingly fast in hardware, and shows a lot of promise as far as
strength. Estimates in hardware are 8Gbits/sec. It's a bit-stream
cipher, vs. a byte stream cipher like RC4.
If this fits your needs, let me know.
Albert
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an
Date: Tue, 19 Sep 2000 19:33:26 +0200
Kostadin Bajalcaliev wrote:
>
> You have spend a time to write a nice survey of the obvious situation
> today. Even agreeing with you in most of your positions there is something
> that I must object. Starting to observe something having in mind that it
> will be not an answer to a given question is a negative position, give a
> chance to some alternative views. You stand behind the position that we will
> never have an exact definition of secure block cipher, that there will be no
> measurement etc, HAVE ANYONE PROVED THAT??? I don't claim I have proved the
> opposite at least not concerning the scientific environment we have today,
> but trying to extract the cause of security from already tested designs may
> not been a general proof but at least give some idea about the definition of
> secure cipher.
As I said, we have long ago disscussed in the group on
the non-existence of a rigorous and practical unit of
strength of ciphers. As far as I know, the only cipher
that offers perfect security is the ideal OTP, which is
however not realizable in practice. Some ciphers are
generally accepted/believed (in particular recommended
by the gurus) to be strong engouh and may be perfectly
o.k. for your applications. On the other hand, that's
like bridges that are built by engineers to stand,
though some did fall down through occurence of unexpected
loadings.
M. K. Shen
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Proper way to intro a new algorithm to sci.crypt?
Date: Tue, 19 Sep 2000 17:21:50 GMT
Can anybody give me a quick run-through of the proper way to introduce a
new algorithm to Sci.crypt?
I'd like to intro a new algorithm here that I just finished up.
Thanks.
Albert
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Dangers of using same public key for encryption and signatures?
Date: Tue, 19 Sep 2000 12:28:23 -0500
Bryan Olson wrote:
> Can't an attacker generate all the plaintext-ciphertext
> pairs he wants anyway?
Not usually, because the attacker doesn't know the key. They
have to force it somehow, either by spying or by submitting
things which then get encrypted as part of the protocol.
Either one takes a long time (again _usually_) there are cases
where it doesn't. For those weird cases where an attacker
can force you to generate many plaintext-ciphertext pairs,
you should change the key very often.
This is another example of how good crypto can end up being
bad security. On a terrabit backbone between routers, you
may want to change the keys once a second!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal? (WARNING: GERMAN)
Date: Tue, 19 Sep 2000 19:42:22 +0200
Runu Knips wrote:
>
> Of course, this attack requires masses of memory, which are
> not available today, but this theoretical weakness is enough
> that people prefer to use 3DES, instead of 2DES.
But that does not say that analysing 2-DES is exactly
as simple and as difficult as DES! That was the point.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Algebra, or are all block ciphers in trouble?
Date: Tue, 19 Sep 2000 17:34:30 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > >if you go writing boolean algebraic
> > >equation at BIT level, it can be demonstrated that
> > >ANY invertible f-function may be built-up by a proper
> > >composition of XOR and NOT function...
> Mack wrote:
> > No any invertible LINEAR function can be build using
> > only XOR, the variables and if nessessary the constant 1
> > NONLINEAR invertible functions require the AND operator.
>
> *Any* Boolean pure function can be written in terms of just:
> NAND
> or
> NOR
> or
> IMPL and NOT
> or
> AND and NOT
> or
> XOR and NOT
> etc. and the input variables.
> .......
please, can you give an example of
how to build the simple AND function
by using only XOR and NOT ?
thanks
Ferdinando
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Algebra, or are all block ciphers in trouble?
Date: Tue, 19 Sep 2000 17:31:53 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
.....
> >ANY invertible f-function may be built-up by a proper
> >composition of XOR and NOT function...
>
> No any invertible LINEAR function can be build using
> only XOR, the variables and if nessessary the constant 1
>
> NONLINEAR invertible functions require the AND operator.
>
OK.
> >(as INVERTIBLE f-function i mean ANY BOOLEAN function of N
> >input bit and 1 output bit where
> >by the knowledge of ANY N-1 input + the output
> >it is possible to retrieve the remaining input bit).
>
> All binary functins of N inputs and one output can
> be solved for the remaining output if they are
> not degenerate in the unknown input bit. Simply
> try one then zero.
>
No: for instance, the AND function:
you may write:
a AND b = c
but you CAN'T extract a or b from the right term to obtain:
a = b ??? c
cause if you know that c=0 and b=0 you can't say what 'a' is.
It was not a matter of trials: it was intended to
break a Feistel-Network by means of an algebraic approach:
writing down a system of N equations of
N unknonws and solving it.
> >Such a composition allows you to extract the unknowns
> >from the "F(x,y,z)" expression:
> >you may simplify your equations, because it will be made
> >by XOR and NOT functions only.......
regards
Ferdinando
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Proper way to intro a new algorithm to sci.crypt?
Date: Tue, 19 Sep 2000 10:46:18 -0700
Albert Yang <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Can anybody give me a quick run-through of the proper way to introduce a
> new algorithm to Sci.crypt?
>
> I'd like to intro a new algorithm here that I just finished up.
>
> Thanks.
> Albert
Miss-spell single syllable words, make unfounded and preposterous claims
and insult anyone who has a clue with reckless abandon.
When folks respond, insult them personally.
Seems to work.
Paul
------------------------------
From: "Sagie" <[EMAIL PROTECTED]>
Subject: Maximal security for a resources-limited microcontroller
Date: Tue, 19 Sep 2000 20:39:09 +0200
Hello all,
I'm in need of a symmetric (secret key) encryption process for one of my
projects. I would love to use one of the popular schemes, such as blowfish
and DES, but the cipher has to be implemented in a teeny-weeny
microcontroller with very limited resources. The cipher's program footprint,
memory footprint and execution time must therefore be as small as possible,
while maintaining the highest security possible (I was thinking about a
process that will take no more than 150 RISC cycles per byte, and a program
footprint of no more than 384 words). Plus I'm also quite a novice in these
issues.
What I had in mind was to implement a non-linear 4-bit or 8-bit lookup
table (8-bit lookup table is as far as I can go -- and it must be used for
both encryption and decryption, which is not a big deal because I can decide
that incoming messages will be encrypted with the decryption key), along
with maybe some bit splicing.
The last line of defence I was thinking of is somehow making the
encryption of every byte dependant of the encryption result of the last
byte. But this raises question as for implementing the decryption process...
So this is basically what I'm asking:
1. Is the "progressive ciphering" (the "last line of defence" described
in the last paragraph) at all possible to perform? If so, how is the
encryption/decryption implemented? (I would appreciate a tutorial source
code/link)
2. Can anyone direct me to a source code that demonstrates (and
explains) how do table-based ciphers are implemented?
3. Is there anything else that can be performed to raise the security
level (within the limits described above)?
4. After doing all of these tricks, how strong is the cipher going to
be?
I hope I'm not asking too much here... I would appreciate any help,
really.
Thanks a lot in advance,
Sagie.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Chosen and known attacks - are they possible ??
Date: Tue, 19 Sep 2000 17:55:14 GMT
Guy Macon wrote:
> Bryan Olson wrote:
> >
> >Consider a subscription satellite-TV service. The content
> >is sent encrypted, and each subscriber has a
> >tamper-resistant box that decrypts it. Now suppose a pirate
> >wants to make working decryption devices. He can subscribe
> >to get a box, then introduce his own data and see what comes
> >out - the chosen ciphertext attack.
>
> That sounds like a chosen plaintext attack to me.
The box one gets by subscribing takes the encrypted
signal and decrypts. It's input is ciphertext.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Software patents are evil.
Date: Tue, 19 Sep 2000 08:14:57 +0200
Terry Ritter wrote:
> Patents on "processes" ("do this, do that") have been common for at
> least a century. Patents on a computational process which ends up
> providing some benefit for use seems a very natural extension.
If you are talking about a physical process that is used to create
something of a physical nature - i agree. But one cannot patent
an idea... (or at least compton newmedia thought so), there is
however zones which are free of all patents: International waters :o)
An example: Something as revolutionary as RSA (when it came) should
be granted a patent, but i do NOT think they should have recieved a
patent as broad as they got. Some Patent offices need to learn to
limit themselves.
Regards,
Glenn
__________________________________________________________________
P.S: Patents on medicine that are in the way of the well beeing of
mankind or progress of sciense are the real evil ones.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption
Date: Tue, 19 Sep 2000 18:16:36 GMT
On Tue, 19 Sep 2000 14:57:01 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[...]
>The specific type of polymorphism in Konstantin Bajalcaliev's designs,
>though, as you can see from looking at Quadibloc II and the others of
>my designs which use it, was basically added almost as an
>afterthought, which is why it is present only in such a rudimentary
>form.
I have looked, but end up more confused than when I started: Exactly
what is it about this "specific type of polymorphism" which
distinguishes from prior work? What is the process at issue:
combining, mixing, what? Are we talking streams or blocks or what?
>If one thinks of not simply choosing between +, -, XOR, and
>multiplication, but of choosing from a large collection of Latin
>squares, there is of course Terry Ritter to think of, but I don't
>think he ever made the choice of Latin square _data_ dependent.
I would say that +, -, XOR and so-on are functions which happen to be
convenient for math, but which each represent just a single
possibility from among the universe of reversible combining functions.
The advantage of the Latin square structure is to support *any*
*possible* fixed discrete reversible combining function (of a given
size) which has statistical balance with respect to both inputs. I
find the literature quite persuasive with respect to the weakness of
combining functions which are not balanced.
On the other hand, my Dynamic Substitution does support a similar
combining effect, continuous change, and statistical balance, in a
much smaller table. The table is changed by transposition as selected
by input data, which might be seen as both "polymorphic" and
data-dependent. But I have no idea whether this is similar to the
mentioned designs.
One might consider a vector consisting of every possible Latin square,
but to the same extent that we can implement it, we limit ourselves.
A reason to select from among a huge universe of possibilities is that
opponents gain no advantage from any pre-selection we may make. So if
we have a subset that can be implemented, we have thrown away the
advantage of having a large universe of possibilities, at least during
operation. We might select a random subset for any particular
message, but of course this is fundamentally just polyalphabetic.
>My suspicion is that polymorphism has been around a long time, but
>mostly in amateur designs.
Exactly how is a cipher distinguished as being an "amateur design"?
I claim that any such concept is fundamentally unscientific: A design
is what it is, and not who did it. It can only matter who did it if
we have no idea how to evaluate the result. And if we don't, then,
realistically, those doing it probably don't either.
>But there may be something in the publicly
>known history of cryptography that is properly considered to be its
>origin.
>
>John Savard
>http://home.ecn.ab.ca/~jsavard/crypto.htm
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: John Rickard <[EMAIL PROTECTED]>
Subject: Re: A conjecture - thoughts?
Date: 19 Sep 2000 19:18:11 +0100 (BST)
Reply-To: [EMAIL PROTECTED]
Andru Luvisi <[EMAIL PROTECTED]> wrote:
: I have the following conjecture:
:
: If f() and g() commute, that is f(g(x)) = g(f(x)) for all x, then
: f() and g() are both powers of some base function, b^y(x_0, x),
: where x_0 and x are the same the first time through, x_0 stays the
: same on every itteration, and the output is fed back into x.
[Later explained that this means that f(x) = b(x,b(x,x)) and
g(x) = b(x,b(x,b(x,b(x,b(x,x))))) or similar with different numbers of
iterations of b().]
This turns out to be true in an uninteresting way, even if f() and g()
do not commute, provided one is working in a domain with more than two
elements. For then one can define b() so that
b(x,f(x)) = g(x);
b(x,x) = (something not equal to x or f(x)), if x =/= f(x);
b(x,y) = f(x), if y =/= x and y =/= f(x).
and then f(x) = b(x,b(x,x)) and g(x) = b(x,b(x,b(x,x))).
With two or fewer elements, one can still find such a b() unless f()
and g() are distinct constant functions, in which case they do not
commute.
If you are trying to find a better version of the conjecture, I'd
suggest considering the possible counterexamples that John Savard has
proposed. (And also consider f(x) = (x xor 1), g(x) = (x xor 2) --
bitwise xor, of course.)
--
John Rickard <[EMAIL PROTECTED]>
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Maximal security for a resources-limited microcontroller
Date: 19 Sep 2000 11:24:43 -0700
"Sagie" <[EMAIL PROTECTED]> writes:
> I'm in need of a symmetric (secret key) encryption process for one of my
> projects. I would love to use one of the popular schemes, such as blowfish
> and DES, but the cipher has to be implemented in a teeny-weeny
> microcontroller with very limited resources. The cipher's program footprint,
> memory footprint and execution time must therefore be as small as possible,
> while maintaining the highest security possible (I was thinking about a
> process that will take no more than 150 RISC cycles per byte, and a program
> footprint of no more than 384 words). Plus I'm also quite a novice in these
> issues.
If you can stand around 350 cycles/byte, try Skipjack, which should
be at least as good as DES, but smaller. See
http://www.brouhaha.com/~eric/crypto/#skipjack
for a sample microcontroller implementation. Program size is around
320 words if you want to encrypt *or* decrypt; close to your 384 if
you want to do both. It needs only 3 bytes of temporary ram, plus
the 8-byte data block plus the 10-byte key.
Another alternative is to use the RC4 stream cipher, which needs less
code space but which needs around 260 bytes of RAM. It will run a lot
faster than Skipjack but imposes some special key management constraints
since it is a stream cipher.
> What I had in mind was to implement a non-linear 4-bit or 8-bit lookup
> table (8-bit lookup table is as far as I can go -- and it must be used for
> both encryption and decryption, which is not a big deal because I can decide
> that incoming messages will be encrypted with the decryption key), along
> with maybe some bit splicing.
>
> The last line of defence I was thinking of is somehow making the
> encryption of every byte dependant of the encryption result of the last
> byte. But this raises question as for implementing the decryption process...
This gives no security at all.
Re general references: get the book _Applied Cryptography_ by Bruce Schneier.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: ExCSS Source Code
Date: Tue, 19 Sep 2000 11:34:12 -0700
Bryan Olson wrote:
> > and b) does this prohibition against including "reasonable"
> > amounts of material in your reviews violate your 1st Amendment
> > right to engage in critical speech?
>
> There is no prohibition against including the material. Your
> right to deliver your speech may have a very different legal
> status from the actions you take to prepare it.
If you must circumvent the access control in order to obtain a snippet of
material to include in your review (because ten years from now VHS has gone
the way of 8-track tapes and all new material comes out on DVD), yes, you are
violating the law. Thus a prior restraint is being placed upon speech. Case
law has long held that prior restraint (that is, a restraint that occurs
during the process of creating or publishing the speech, but before the speech
has actually been delivered) is identical to actual published speech insofar
as its 1st Amendment implications goes. See, e.g., the Pentagon Papers case,
where the Feds argued that it was permissible to suppress publication of the
Pentagon Papers because they had not yet been published and thus were not yet
speech... the Suprememes swatted them down like flies.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
Date: Tue, 19 Sep 2000 15:00:13 -0400
From: dbf <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Figures of Merit for Crypto=Systems
I wonder if some of the users of this excellent newsgroup could give me
some help. I would like to have a list of figures of merit (FOM)for
evaluating cryptosystems, To set the boundries of the problem I only
want to consider systems useful for "average" PC's (1-200MHZ w/Windows
95), with the system embodied as an MSDOS executable. I only want to
consider the properties of the plaintext-cyphertext-plaintext algorithm.
Other things like public/private keys,authorizations and signatures
aside. As a base point consider a plaintext of 100 words. Here are some
FOM's I have come up with:
1. coding time/100 words
2. decoding time /100 words
3. ratio of cyphertext bytes/plaintext bytes (I have seen 30 bandied
about)
4. Redundancy. In order to foil frequency analysis the same plaintext
element (say the letter "e") should never be represented by a given
cyphertext element more than once in a single message. How many
representationsare needed? And in successive messages the set of
cyphertext elements representing a given plaintext element should be
different. how many sets?
What FOM's for these are state-of-the-art? What is considered adequete?
What other FOM's are there?
I am thinking of the simplest type of code, e.g. a list of numbers
attached to an e-mail. One that an untrained, casual PC user can learn
in just a few minutes. One suitable for a small business. PGP is too
hard. I want to remind the experts reading this that their expertise was
gained after much hard work. Few people are willing to invest such
effort.
Thanks for your help-dbf
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: BUG In CryptLib3 - by Peter Gutmann. Is there a fix? - Additional info
Date: Tue, 19 Sep 2000 17:53:23 +0100
Well I modified it a little to run from the command line. and it worked fine
5 times in a row.
d:>cl bug.cpp cl32.lib
Mike Scott
===================== bug.cpp ===================
#include <stdio.h>
#include "cryptlib.h"
#define CHECKCODE(st) if (st){ char Txt[100]; printf (Txt,"Error %u Line:%u
", st, __LINE__);\
/* MessageBox (NULL, Txt,"Error", MB_OK); */}
void main()
{
int status;
status = cryptInit();
status = cryptAddRandom( NULL, CRYPT_RANDOM_SLOWPOLL );
for (int i=0;i<100;++i)
{
printf("i= %d\n",i);
// Create the public key
CRYPT_CONTEXT privKeyContext;
status = cryptCreateContext( &privKeyContext,
CRYPT_ALGO_RSA);
CHECKCODE (status);
status = cryptSetAttributeString( privKeyContext,
CRYPT_CTXINFO_LABEL, "Ga", 2);
CHECKCODE (status);
status = cryptGenerateKeyEx (privKeyContext,1024/8);
CHECKCODE (status);
status = cryptDestroyContext (privKeyContext);
CHECKCODE (status);
}
status = cryptEnd();
CHECKCODE (status);
}
===============================
<[EMAIL PROTECTED]> wrote in message news:8q811l$o98$[EMAIL PROTECTED]...
> The following code "hangs up" under Windows NT - Visual Studio 6.0 SP3.
> I'm using Peter Gutmann's CryptLib 3.0, downloaded from:
> ftp://ftp.franken.de/pub/crypt/cryptlib/beta/cl30beta02.zip
> on 30/08/2000.
> The program causes an exception randomly. It rarely finishes the 100
> times loop without causing the exception.
> -------------------------------------------------------------------
>
> #define CHECKCODE(st) if (st){ char Txt[100]; sprintf (Txt,"Error %u
> Line:%u ", st, __LINE__);\
> MessageBox (NULL, Txt,"Error", MB_OK);}
>
> void TestLib(void)
> {
> int status;
>
> status = cryptInit();
> status = cryptAddRandom( NULL, CRYPT_RANDOM_SLOWPOLL );
>
> for (int i=0;i<100;++i)
> {
>
> // Create the public key
> CRYPT_CONTEXT privKeyContext;
>
> status = cryptCreateContext( &privKeyContext,
> CRYPT_ALGO_RSA, CRYPT_MODE_PKC );
> CHECKCODE (status);
>
> status = cryptSetAttributeString( privKeyContext,
> CRYPT_CTXINFO_LABEL, "Ga", 2);
> CHECKCODE (status);
>
> status = cryptGenerateKeyEx (privKeyContext,1024/8);
> CHECKCODE (status);
>
> status = cryptDestroyContext (privKeyContext);
> CHECKCODE (status);
> }
>
> status = cryptEnd();
> CHECKCODE (status);
> }
>
> ------------------------ ASSERTION INFO -------------------------
> File: cryptdev.c
> Line: 102
> Expression: NOTREACHED
> -----------------------------------------------------------------
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Sagie" <[EMAIL PROTECTED]>
Subject: Re: CDMA tracking (was Re: GSM tracking)
Date: Tue, 19 Sep 2000 21:01:02 +0200
I believe the aluminum briefcase is more than enough for a CDMA cellphone,
due to the following reasons:
1. While off, the cellphone does not transmit -- it only receives. It
will only transmit when told to do so, which requires the phone to receive
that message from the network. The briefcase is enough to block phone
reception from any cellular system.
2. Keep in mind that CDMA is based on spread-spectrum. This makes the
actual power-per-frequency rating much lower than any other cellular system,
and therefore the briefcase should not have any problem defeating the
phone's transmission. The signal-to-noise level outside the briefcase would
be so low that the original signal could never be reconstructed (or sensed,
for that matter).
3. The aluminium briefcase is much bigger than the phone, and is
therefore a sufficient ground space (compared to the phone's tiny ground
space).
Sagie.
"H. Ellenberger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Mack wrote:
>
> > >If you are concerned about your phone being
> > >trackable when it is off, why not just put
> > >it in an aluminum briefcase ?
>
> > Not terribly effective at attenuating signals.
> > It must be properly grounded. The 50 foot of ground
> > cable limits the effective range of the phone.
>
> Completely wrong, no ground cable is required.
> If the metal briefcase should leak too much rf power,
> just put it into a small and tight metallic box.
>
> HE
>
>
------------------------------
From: "Sagie" <[EMAIL PROTECTED]>
Subject: Re: Music Industry wants hacking information for cheap
Date: Tue, 19 Sep 2000 21:17:00 +0200
So I suppose your one of those guys that actually do acquire DVDs from
your own region alone? ;)
Seriously now, any type of content restriction that has been presented,
to this date, is already defeated/ignored. I suppose you did not know this,
but your audio CDs also contain a copy-protect flag that theoretically
should have stopped any CD ripping action from taking place. The point is
that nobody cares about it, just as most DVD players don't care much about
regions. This is the same future that is expected for this SDMI.
Besides, if manufacturers would actually go through this, you can be
certain that SDMI-signal-defeaters would arise, and that your local
electronics repairman would happily re-arrange the internal circuitry of any
SDMI compliant player you would give to him.
"Scott Craver" <[EMAIL PROTECTED]> wrote in message
news:8q171c$b0f$[EMAIL PROTECTED]...
> Daniel Leonard <[EMAIL PROTECTED]> wrote:
> >On Wed, 13 Sep 2000, David C. Barber wrote:
> >
> >> (SDMI for the not completely informed is Secure Digital Music
Initiative.
> >> The concept is that they can embed information into the music stream
that
> >> cannot be filtered out, will survive various
> >> decompression/recompression/format conversions, and will still tell
SDMI
> >> compliant players not to play or allow copies. This is all while the
rest
> >> of the world chugs along on MP3.)
> >
> >As someone said here no long ago, intercept and record the data stream
> >between the apps that does the decyphering and the driver for the
> >videocard, you will get the plaintext...
>
> This won't work. The technology in question is not encryption,
> but steganography. The "plaintext" contains within it the
> "don't play me" label, and it is not removed before being sent
> to the speakers.
>
>
> >Daniel L=E9onard
>
> -S
>
------------------------------
** 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
******************************
