Cryptography-Digest Digest #641, Volume #12 Sat, 9 Sep 00 12:13:01 EDT
Contents:
Re: ExCSS Source Code (Ichinin)
Re: RSA?? ([EMAIL PROTECTED])
Re: PRNG ([EMAIL PROTECTED])
We perform a comprehensive analysis of practical quantum cryptography (QC) (John
Bailey)
Re: RSA?? ("Big Boy Barry")
Re: Losing AES Candidates Could Be a Good Bet? (SCOTT19U.ZIP_GUY)
Re: Losing AES Candidates Could Be a Good Bet? ([EMAIL PROTECTED])
Re: RSA?? ([EMAIL PROTECTED])
Scottu19 Broken ([EMAIL PROTECTED])
Re: Camellia, a competitor of AES ? (Samuel Paik)
Re: Scottu19 Broken (John Savard)
Re: Losing AES Candidates Could Be a Good Bet? (John Savard)
Re: Known Plain Text Attack (Mack)
Re: Losing AES Candidates Could Be a Good Bet? ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters (Chris Rutter)
Re: Bytes, octets, chars, and characters (Chris Rutter)
Re: blowfish problem (Chris Rutter)
Re: Security of whitening alone? (David A. Wagner)
Re: Scottu19 Broken ([EMAIL PROTECTED])
Re: How weak is the encryption in the old NORTON NAVIGATOR (NORTON FILE MANAGER)
(Mack)
Intel's 1.13 MHZ chip (Mok-Kong Shen)
Re: blowfish problem (Larry Weiss)
Re: How weak is the encryption in the old NORTON NAVIGATOR (NORTON FILE MANAGER)
(JPeschel)
Re: Known Plain Text Attack (Terry Ritter)
Re: Losing AES Candidates Could Be a Good Bet? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: ExCSS Source Code
Date: Sat, 09 Sep 2000 02:13:09 +0200
Wim Lewis wrote:
> I don't know why you think that what I wrote suggests what you
> wrote. The DMCA prohibits the circumvention of "technological
> protection measures", which CSS is argued to be, regardless of
> distribution, regardless of what it's used for[1]. I believe
> that the DMCA also outlaws distributing information about how
> to circumvent TPMs, which also covers DeCSS.
CSS does NOT protect against copying, you can still copy a DVD
just as easy as a paper, since the decryption keys are copied
as well when you copy the DVD data from one medium to another,
which allows for proper playback in any cd = CSS is bullocks!
It's only EFFECTIVE MEASURABLE property is the region codes.
Regards,
Glenn
(.SE)
(And again... DMCA is VOID outside the US.)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA??
Date: Sat, 09 Sep 2000 11:36:32 GMT
In article <eIju5.248105$[EMAIL PROTECTED]>,
"Big Boy Barry" <[EMAIL PROTECTED]> wrote:
> Is RSA encryption unsecure? I know nothing is 100% secure... but I
would
> like your opinion on RSA?
Um, no to the best of my knowledge when used correctly RSA is still
considered secure.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PRNG
Date: Sat, 09 Sep 2000 11:37:36 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (S. T. L.) wrote:
> /* DIEHARDC ok (no 0.00 no 1.00) */
>
> This is not the way to interpret DieHard results.
Technically there is no valid way to interpret DH results...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: We perform a comprehensive analysis of practical quantum cryptography (QC)
Date: Sat, 09 Sep 2000 12:36:18 GMT
MITRE TECHNICAL REPORT
Practical Quantum Cryptography: A Comprehensive Analysis
by G. Gilbert and M. Hamrick
September 2000
http://xyz.lanl.gov/abs/quant-ph/0009027
should be of interest.
(quoting from the abstract)
We perform a comprehensive analysis of practical quantum cryptography
(QC)systems implemented in actual physical environments
(1) We obtain the complete universal expressions for the effective
secrecy capacity and rate for QC systems
(2) We perform for the first time a detailed, explicit analysis of all
systems losses due to and errors and noises.
(3) We calculate for the first time all system load costs associated
to classical communication and computational constraints that are
ancillary to, but essential for carrying out, the pure QC protocol
itself.
(4) We introduce an extended family of generalizations of the
Bennett-Brassard (BB84) QC protocol that equally provide unconditional
secrecy .(BB84 = C.H. Bennett and G. Brassard, in Proc. IEEE Int.
Conference on Computers, Systems and Signal Processing, IEEE Press,
New York (1984))
(5) We obtain universal predictions for maximal rates that can be
achieved with practical system designs
(end quote)
Quantum Communications (not computing )sounds like its ready for prime
time. (No pun intended)
John
------------------------------
From: "Big Boy Barry" <[EMAIL PROTECTED]>
Subject: Re: RSA??
Date: Sat, 09 Sep 2000 12:39:43 GMT
Can any government in the world crack it?
<[EMAIL PROTECTED]> wrote in message news:8pd7c1$ck6$[EMAIL PROTECTED]...
> In article <eIju5.248105$[EMAIL PROTECTED]>,
> "Big Boy Barry" <[EMAIL PROTECTED]> wrote:
> > Is RSA encryption unsecure? I know nothing is 100% secure... but I
> would
> > like your opinion on RSA?
>
> Um, no to the best of my knowledge when used correctly RSA is still
> considered secure.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: 9 Sep 2000 12:35:15 GMT
[EMAIL PROTECTED] (Chris Rutter) wrote in
<[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>
>> Actually the losing candidates would most likely be a bad beat.
>> Becasue they most likely would have never gotten in front of the
>> public unless the NSA precieved them as weak. You are correct
>> that the so called winning candidate we be subjected to analysis
>> which may see the light of public some day. But I feel is is only
>> makes sense to use something other than any of the AES candiates
>> if you want security.
>
>This doesn't reconcile with how I understand the NSA's operative goals.
>
>The NSA is interested in trapping, decoding, sifting and protecting
>information which has a relevance to their national security; I imagine
>that their interest in consumer transactions, personal email
>correspondance and so forth will be vanishing. The majority of the
>use of the eventual AES cipher will be, I imagine, in precisely these
>sorts of corporate and consumer transactions.
What on earth would make you think they don't want to cast a large
net and search through all info.
>
>The bad guys have expert cryptanalysts on their side: they don't
>necessarily succumb to a standard like the AES when its security
>properties in the face on the NSA, from a political theorist point of
>view, look questionable. Thus they can and perhaps will use massively
>overspecified encryption to take no chance: after all, do you think the
>idea of using a massively-popular cipher appeals, ideologically, to
>people trying to remain as underground and covert as possible?
>
Actaully the bad guys will buy tainted crypto devices from the
Swiss or some other source that has been on the news. Also the
need to track drug money will ensure banking systems never have
safe crypto.
>I thus assume that the NSA probably has little interest either way in
>whether it can or cannot break AES.
>
>c.
>
I think your wrong. They want to read everything and do not want
common people criminial or not to have the capability to communicate
in secret.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: Sat, 09 Sep 2000 13:21:00 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Actaully the bad guys will buy tainted crypto devices from the
> Swiss or some other source that has been on the news. Also the
> need to track drug money will ensure banking systems never have
> safe crypto.
Now you are dragging the Swiss into your insane arguments? Who's next
the Canadians?
> >I thus assume that the NSA probably has little interest either way in
> >whether it can or cannot break AES.
> >
> >c.
> >
>
> I think your wrong. They want to read everything and do not want
> common people criminial or not to have the capability to communicate
> in secret.
Really, who cares what the heck you think. Provide one gram of proof
to back up any of your arguments. That would be a miracle in itself.
BTW I still think the NSA broke Scottu19, but I don't need to prove
it. It's a common fact you know.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA??
Date: Sat, 09 Sep 2000 13:18:11 GMT
In article <jcqu5.223962$[EMAIL PROTECTED]>,
"Big Boy Barry" <[EMAIL PROTECTED]> wrote:
> Can any government in the world crack it?
Why not find out yourself?
Your not really asking realistic questions. Can RSA be broken? Yes it
can. Is breaking a proper implementation of RSA easy? No. There is a
big difference.
Can the govt break RSA? Probably a bit better then the open since if
required they could prob get more computers and power. Factoring is a
well studied problem and given all that the experts know RSA is
consider secure iff it's implemented and used properly.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Scottu19 Broken
Date: Sat, 09 Sep 2000 13:26:23 GMT
I heard that the NSA broke Scottu19, is that true?
P/b
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: Camellia, a competitor of AES ?
Date: Sat, 09 Sep 2000 14:24:41 GMT
In article <8pbvh8$491$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
> This is nice, but does it tell us whether Camellia will be
> released to the public domain ?
No. ISO does not require holders of patents which cover
International Standards to release their patents into
the public domain. Many examples abound, I'm more
familiar with digital media standards, e.g. JPEG and
MPEG; there is an organization for MPEG which sets
pooled royalty rates, collect the royalties from
users (manufacturers of products like DVD players),
and distribute the proceeds back to the patent holders.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Scottu19 Broken
Date: Sat, 09 Sep 2000 14:41:40 GMT
On Sat, 09 Sep 2000 13:26:23 GMT, [EMAIL PROTECTED] wrote, in
part:
>I heard that the NSA broke Scottu19, is that true?
A weakness was found in some earlier versions of his cipher, I forget
which ones, by people on this newsgroup.
But why would the NSA concern itself with Scott19u, as, although it
may well be secure, I doubt that anyone is taking it seriously enough
to use it - for reasons unrelated to its security as a cipher.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: Sat, 09 Sep 2000 14:49:11 GMT
On Fri, 8 Sep 2000 20:01:12 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>Mok-Kong Shen wrote:
>> For any non-trivial modern cipher (not of the snakeoil
>> category), the chance of having a superencipherment that
>> weakens it is negligible in my humble view, ...
>There is always the possibility of "destructive resonance"
>at interfaces in a pipeline of algorithms; see "Predicting
>the Output of a Linear Congruential Generator Encrypted
>with ElGamal" by John A. Malley for an example. Another
>example would be somebody who takes a secure cipher and
>uses it to seed an insecure one, or to generate OTP key
>that is then reused for multiple messages. The mere fact
>of a secure subsystem being a component does not guarantee
>that the overall system is secure.
You're both right.
Let's say that Super-DES is a wonderful block cipher. (Specifically,
it is to resist known-plaintext attacks.)
If the key used for Super-DES is passed insecurely in another cipher
that is broken, or generated by a PRNG that is weak, or if Super-DES
is only used in producing keys for a weak cipher, then indeed, as you
say, the result can be broken.
On the other hand, if a message is enciphered _properly_ with
Super-DES, then enciphering it before or after by some weak method as
well is indeed unlikely to cause problems.
Of course, if you encrypt with Super-DES, then convert to, say,
printed hexadecimal characters, and encrypt them using a weak method
_with the same key_, then of course the _whole_ cipher will be
breakable.
However, I don't regard this as particularly surprising.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Known Plain Text Attack
Date: 09 Sep 2000 14:58:26 GMT
>Thanks for the support Mack.
>Do you know where can I find some e-books about encryption, maybe
>courses ?
> I am from Romania and unfortunatley I don't study encryption this year
>at the university and I haven't seen some good books around here about
>encryption either.
>
>JohnD.
>
The good ones I have seen online are
The handbook of applied cryptography
http://cacr.math.uwaterloo.ca/hac/
John Savard's collection
http://home.ecn.ab.ca/~jsavard/crypto.htm
Of course Terry Ritter has a llarge collection of
material. But beware some of it is pattented
so check before using the methods.
http://www.io.com/~ritter/
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: Sat, 09 Sep 2000 15:03:07 GMT
[EMAIL PROTECTED] wrote:
> Now you are dragging the Swiss into your insane arguments? Who's next
> the Canadians?
Be careful, they're up there and just waiting for the chance to cross
the world's longest unprotected border and shop in our malls!
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Chris Rutter <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Sat, 9 Sep 2000 15:15:25 +0100
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> If it weren't for the historical ambiguity about whether plain
> "char" is signed or unsigned, we could dispense with "signed"
> altogether, since it's the default for all other integer types.
There are problems with this: sign-extension of `char' into an internal
register either does or does not occur `naturally' on a given
architecture, and forcing `char' to behave with the opposite signedness
to the underlying architecture incurs significant penalties.
In a vast majority of cases where `char' simply gets `passed through',
and no arithmetical operation is performed where the signedness is
important, it's a performance hit to rearrange its signedness.
It's probably possible in the majority of cases to determine whether
such arithmetical operations would be performed and sign-extend or
-reduce, but not all compilers are geared up to do this.
This is probably symptomatic of C's taste for codifying existing
efficient architecture-specific practices, rather than a more
architecture-homogeous style with emphasis on easy (or lazy) portable
I/O. It's part of the reason why both portable and nonportable systems
software gets written in C.
c.
------------------------------
From: Chris Rutter <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Sat, 9 Sep 2000 15:43:14 +0100
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> It's too bad that integers weren't initially called int8, int16, etc,
> with no "short" or "long" types. If that had been done, we wouldn't
> have to worry about this type of problem now.
Interestingly, one of the UK C99 delegation members proposed an idea
along these lines: <http://www.doves.demon.co.uk/cstd.html>.
> Of course, we might then
> have wanted a type word, hword, and dword *in addition* to specifically
> refer to a machine register, half of a register, or two registers... but
> unless I misrecall, some compilers have these defined.
This does at least capture both the (conflicting) interests of use of C:
* as a `better assembler', allowing programs that would have been written
directly in a machine code instruction assembler, such as great swathes
of an operating system, to be expressed more concisely, with easier-to-
track-down bugs in a higher-level flavour;
* as a widely portable language for implementing high-level software with
predictable I/O semantics embedded in the language.
In the former, it's important to have C types which are simply represented
in a form natural to the architecture, such that assembler code and C
can be easily intermixed.
In the latter, one wants to be able to interpret data `from the wire'
easily, with the minimum of effort devoted to marshalling the data into
a local form.
However, I think introducing a plethora of types to this end would be a
grave mistake.
In fact, to be honest, I think constraining the standard C types at all
is a mistake: one might as well suggest that all `int' types should be
little-endian, for instance. Sacrificing the simplicity of the language's
implementation just to make all C storage and operations rigidly
predictable would be a fundamental loss, and the language implementations
would become increasingly inefficient, and have to fight back with ever-
more-complex analysis to try to cut corners of the Standard where
possible, making the languge barriers increasingly unpredictable and
hostile to intermix.
Writing software that doesn't make assumptions about the C types, other
than the largest number that can be stored therein, is a lot easier than
people seem to make out: yes, it requires thought, but there are plenty
well-worked-through examples out there to study.
C types are defined, to my mind, by the types of application to which
they are most efficiently suited: and this is surely, more often than
not, an important part of the criteria for implementing any piece of
software: writing a Linux port, for instance, people may be unconcerned
about the exact storage natures of the majority of the types: what they
want is something that's guaranteed to be dealt with in a way most
natural to the machine at an underlying level, given that it supports
a basic range of operations.
If C is not to become trapped in the past -- a relic of days when
processor architectures happened to be 32-bit -- it must stick to its
ideology. Condemning C, as Java, to deal in 32-bit types once and for
all seems a grave mistake. It isn't acceptable to define it as a
`temporary standard' which will be redefined on the advent of faster
and better technology either: this just peddles a dangerous fiction
which leaves the corpus of software written in C trapped back with an
old language standard. And because there /is/ only a limited amount
of compile-time analysis to which C can be subjected, it won't always
be possible, in the future, to tell what really does rely on antiquated
type-width assumptions and what doesn't: and thus these assumptions
should never be introduced in the first place.
However, judging from the lame effort of C99, this isn't what appears
to be happening.
c.
------------------------------
From: Chris Rutter <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sat, 9 Sep 2000 15:51:17 +0100
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> With exceedingly rare exception, if a program strictly conforms
> to the 1989 C standard it also conform sto the 1999 C standard.
Perhaps in terms of strict conformance as a piece of C code, but as a
piece of code that has to function and run, the case isn't so rosy.
For instance, the C89 way to output a denary representation of a
`sizeof_t' was to cast it to an `unsigned long', which was guaranteed
to hold the largest range of positive numbers of any type. This assumption
no longer holds; this isn't irrelevant, either: manipulating objects
describing the size of extremely large files, for instance, can fall over
catastrophically if casts to `unsigned long' are now used.
c.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Security of whitening alone?
Date: 9 Sep 2000 08:25:50 -0700
Yes, this can be converted to a known-plaintext attack, with
advanced techniques: e.g., 2^{b/2} known texts and 2^{b/2} work
suffice to break the scheme. See
``Advanced Slide Attacks.'' Alex Biryukov and David Wagner. EUROCRYPT 2000.
http://www.cs.berkeley.edu/~daw/papers/advslide-ec00.ps
By the way, your proposed scheme (just pre- and post-whitening,
with an unkeyed permutation) is known as the Even-Mansour scheme,
after a paper they wrote giving some proofs of security for it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Scottu19 Broken
Date: Sat, 09 Sep 2000 15:21:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Sat, 09 Sep 2000 13:26:23 GMT, [EMAIL PROTECTED] wrote, in
> part:
>
> >I heard that the NSA broke Scottu19, is that true?
>
> A weakness was found in some earlier versions of his cipher, I forget
> which ones, by people on this newsgroup.
>
> But why would the NSA concern itself with Scott19u, as, although it
> may well be secure, I doubt that anyone is taking it seriously enough
> to use it - for reasons unrelated to its security as a cipher.
Oh now I have to give reasons? Nah. NSA likes breaking all crypto
espescially from fanatics.
P/b
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: How weak is the encryption in the old NORTON NAVIGATOR (NORTON FILE
MANAGER)
Date: 09 Sep 2000 15:32:07 GMT
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Very weak, replace asap.
>
>On Wed, 06 Sep 2000, [EMAIL PROTECTED] (HeWhoCannotBeNamed) wrote:
>>It lets you encrypt files/folders. It's several years old, but I still use
>it
>>as a great file manager in WIN95 (and works in win98, at least for me). I
>>don't know much at all about encryption, but I'm wondering whether I have
>>decent safety by encrypting my confidential files with this program (if my
>>laptop gets stolen). I don't know of anyway to find out what kind of
>>encryption algorithm it uses. I can't find out from Norton, since the
>>program is about 5 years old.
>
>
>~~~
>This PGP signature only certifies the sender and date of the message.
>It implies no approval from the administrators of nym.alias.net.
>Date: Sat Sep 9 05:06:04 2000 GMT
>From: [EMAIL PROTECTED]
>
If I recall correctly, it uses a version of DES but it converts
all lower case characters to upper case. And since it used
the password directly it is limited to 8 characters. I could be
remembering a different program however.
The following I am sure on:
Also it met the exportability requirements which were 40 bit
maximum. Therefore it is well within the cracking range
of a good system.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Intel's 1.13 MHZ chip
Date: Sat, 09 Sep 2000 17:59:29 +0200
Intel has launched a call-back of its 1.13 MHZ Pentium III,
leaving currently AMD's 1.1 MHZ Athlon at the head of the
line.
This shows once again that in information processing there
is much more to be worried about than algorithmics alone.
Compatibility of hardware/software of the communication
partners needs to be assured and diverse forms of
redundancy may be called for in certain critical
applications. I guess that such issues are no less
important than questions like whether the opponent
can obtain the 2^m pairs of plaintext and ciphertext
(m sufficiently large) which the theory shows is
sufficient/necessary for him to get the key.
M. K. Shen
------------------------------
From: Larry Weiss <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sat, 09 Sep 2000 10:50:27 -0500
"Donald L. Nash" wrote:
> Paul Schlyter wrote:
> >Actually, the CDC 6600 had an altneraive character encoding, which
> >used 12 bits ber character. In CDC jargon, this was called "ASCII",
>
> Here at UT (where we had a 6600 and a 6400, and then two Cyber 750s by
> the time I came along), it was called "8-in-12 ASCII" for obvious
> reasons. I don't know if this was a local UT nomenclature or something
> from CDC.
> Donald L. Nash, <[EMAIL PROTECTED]>, PGP Key ID: 0x689DA021
> The University of Texas System Office of Telecommunication Services
I guess everything really is bigger in Texas (even an ASCII char).
- Larry Weiss
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: How weak is the encryption in the old NORTON NAVIGATOR (NORTON FILE
MANAGER)
Date: 09 Sep 2000 15:57:32 GMT
[EMAIL PROTECTED] (Mack) writes:
>If I recall correctly, it uses a version of DES but it converts
>all lower case characters to upper case. And since it used
>the password directly it is limited to 8 characters. I could be
>remembering a different program however.
>
Sounds like you're thinking of the old Norton Discreet, Mack,
not Navigator.
Peter Gutmann looked at [In]Discreet about seven years ago,
and mentioned that the program also used a proprietary
encryption method besides the mangled DES implementation.
>The following I am sure on:
>Also it met the exportability requirements which were 40 bit
>maximum. Therefore it is well within the cracking range
>of a good system.
Yup.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Known Plain Text Attack
Date: Sat, 09 Sep 2000 15:59:41 GMT
On 09 Sep 2000 14:58:26 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Mack) wrote:
>>Thanks for the support Mack.
>>Do you know where can I find some e-books about encryption, maybe
>>courses ?
>> I am from Romania and unfortunatley I don't study encryption this year
>>at the university and I haven't seen some good books around here about
>>encryption either.
>>
>>JohnD.
>>
>
>The good ones I have seen online are
>
>The handbook of applied cryptography
>
>http://cacr.math.uwaterloo.ca/hac/
>
>John Savard's collection
>
>http://home.ecn.ab.ca/~jsavard/crypto.htm
>
>Of course Terry Ritter has a llarge collection of
>material. But beware some of it is pattented
>so check before using the methods.
>
>http://www.io.com/~ritter/
I find this fear of patents very odd:
First of all, my US patents apply only in the US, and the question is
from Romania.
Next, if the issue is *understanding* cryptographic techniques,
avoiding patented concepts is an explicit choice for ignorance.
If the issue is "why should I do anything that may make somebody else
some money," the answer, presumably, is that studying something which
is ignored by others puts you that much ahead in your own game.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: Sat, 09 Sep 2000 18:15:51 +0200
[EMAIL PROTECTED] wrote:
>
> [EMAIL PROTECTED] wrote:
> > Now you are dragging the Swiss into your insane arguments? Who's next
> > the Canadians?
>
> Be careful, they're up there and just waiting for the chance to cross
> the world's longest unprotected border and shop in our malls!
Quite a time back there were indeed some rumours about
a European crypto equipment manufacturer that naturally
issued a dementi. I haven't followed that history, though.
M. K. Shen
------------------------------
** 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
******************************
