Cryptography-Digest Digest #467, Volume #14 Tue, 29 May 01 01:13:00 EDT
Contents:
Re: Good crypto or just good enough? ("Sam Simpson")
Re: Quantum Computers with relation to factoring and BBS ("AY")
Re: A new technology for internet security? (David Hopwood)
Re: Quantum Computers with relation to factoring and BBS ("Roger Schlafly")
Re: Quantum Computers with relation to factoring and BBS (John Savard)
Cool Cryptography Website! (John Savard)
Between Silk and Cyanide code question (Bob Wandstraat)
Re: Quantum Computers with relation to factoring and BBS (Charles Blair)
Re: Medical data confidentiality on network comms (Samuel Paik)
Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
Re: Cool Cryptography Website! (JPeschel)
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
Re: Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
Re: To prove PGP can easily be misused... (wtshaw)
Call for Beta Testers - HexEdit 2.1 (Andrew Phillips)
----------------------------------------------------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Tue, 29 May 2001 00:53:21 +0100
"David Hopwood" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Sam Simpson wrote:
> > "Mark Wooding" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Sam Simpson <[EMAIL PROTECTED]> wrote:
> > >
> > > > Is this a suspicion or is there a proof for this somewhere?
> > >
> > > Suppose that A is an adversary which distinguishes triple-DES from a
> > > random permutation within some given resource bounds (say, less than
> > > 2^{56} time). Then construct an adversary B which distinguishes
single-
> > > DES by choosing two more DES keys at random, and giving A the provided
> > > single-DES-or-random-permutation oracle and two further rounds of DES
as
> > > its oracle. B will distinguish single-DES from a random permutation
in
> > > the same resources as A except for three times as many DES
encryptions.
> > >
> > > Will that do you?
> >
> > It's certainly interesting!
> >
> > I'm thinking back to a paper (probably Schneier) where they found an
attack
> > where 2-key 3DES was stronger than 3-key 3DES.
>
> That was a related key attack, assuming you're referring to
>
> John Kelsey, Bruce Schneier, David Wagner,
> "Key-Schedule Cryptanalysis of IDEA, G-DES, GOST, SAFER, and
Triple-DES".
> http://www.counterpane.com/key_schedule.html
Yes, that's the one. Read it some time ago...........
> > You seem to provide a proof
> > for a specific class of attack, but may there be other attacks where the
> > security [of DES and 3DES] could be found to be equivalent?
>
> It's unlikely that they would be found to be *equivalent* under any
attack.
> Kelsey, Schneier, and Wagner's attack is still more difficult than
breaking
> single-DES (since it requires a meet-in-the-middle attack on double-DES),
> even if the related-key conditions hold.
Indeed.
I think the point I was trying to make was that 2 key 3DES intuitively
would be though weaker than 3 key DES, but this isn't always the case.
As David has kindly confirmed in a post in this thread, there is no proof
that 3DES offers any more security than DES. Sure, intuition says that it
should, but...........
> > I guess I'm asking: does your proof imply that, for all attacks, 3DES is
> > stronger that DES?
>
> No, Mark Wooding's proof assumes random keys (which implies that the 3
> single-DES keys are independent), so it does not apply to related key
> attacks. However, you can make a strong argument that such attacks should
> be prevented at the protocol level, so if the algorithm itself prevents
> them, that is just a bonus. If you look at section 3.3 of the Kelsey,
> Schneier, and Wagner paper, which tries to give a motivation for why
> related key attacks on ciphers are important, all the examples given
> rely on serious protocol flaws.
Assuming unrelated keys, what is the proof that 3DES is stronger than DES?
> The other case where related-key attacks are significant is when
constructing
> a hash function from a cipher. However, that's because the constructions
that
> attempt to do this rely on much more than the standard security
definitions
> for ciphers; it's very easy to create examples of ciphers that are secure
> when used for symmetric encryption, but insecure when used a hashing mode
> such as Davies-Meyer, etc. Personally I consider that to be a flaw in
these
> hashing modes; I prefer dedicated hashes.
Good point.
Thanks for the comments,
--
Sam Simpson
http://www.scramdisk.clara.net/
------------------------------
From: "AY" <[EMAIL PROTECTED]>
Subject: Re: Quantum Computers with relation to factoring and BBS
Date: Tue, 29 May 2001 01:09:13 +0100
But then you'd be more interested in the functional problems.
I wish to point out explicity that problems such as "what are the factors of
n" are *neither* in P or NP becuase they are NOT decision (YES/NO) problems.
They live in classes such as FP, FNP and TFNP (total FNP). This is not to
say the decision problems are not related to functional problems, because in
many cases they are, but one would need to be more precise about the
complexity classes in order to analyse them formally.
The book Computational Complexity (Addison-Wesley) by C. H. Papadimitriou
has everything you'd want to know about complexity classes (and more).
AY
------------------------------
Date: Mon, 28 May 2001 22:33:01 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: A new technology for internet security?
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
> A US firm claims to have developed a new technology for
> internet security though varying the IP addresses:
>
> http://dailynews.yahoo.com/h/nm/20010521/wr/tech_security_dc_1.html
I don't see how this would have the slightest effect against attacks on
application-level protocols (exploiting insecure CGI scripts or e-mail
clients that run executables, for example), which are the biggest
practical threat anyway. Also, it introduces all the same protocol
incompatibility problems as Network Address Translation.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOxLD2zkCAxeYt5gVAQG1bQgAiS5pp4DY+NyD8wepBzHyNI5KfPzbzwOx
VzB3I6SK4WjqHYAiFkrEmU5mWF8A5H89B7H6AuMllUFCSiBQCZQ1XVCYQTGNSsDL
QPV+qsEZlhFNfQoxTXiIz9wE8T2gMRKlDXbLPkAALm79WQMVRLm3bXX2cWvpUfCf
zmUi/+My7SYS64N6IqyyG7erFjpCcAZuDXsKb78RCZPK6kZy63Orb6kb7pIfC1L9
5QJg7sCIqtc8lAI9nAgVjykkq1CWzsqxpjY7ytuGJCDlNxKRXGDIfteAMYtyi0AE
OAqzZS8XPuxyMhRMujMCJ2lChmJKhckwenTVtP/vpwwCxX1NA0Us3Q==
=NAeZ
=====END PGP SIGNATURE=====
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Quantum Computers with relation to factoring and BBS
Date: Mon, 28 May 2001 23:21:44 GMT
"Charles Blair" <[EMAIL PROTECTED]> wrote
> As far as I know, it is still open whether factoring is NP-complete.
> Thus, it is possible that there is a polynomial-time algorithm for
> factoring (on traditional, non-quantum computers) but that there
> is no such algorithm for things like the travelling salesman problem.
It is also possible that there is a polynomial time algorithm for
the traveling salesman problem.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Quantum Computers with relation to factoring and BBS
Date: Tue, 29 May 2001 01:08:19 GMT
On 28 May 2001 17:20:24 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote,
in part:
>So would a Turing machine. A Turing machine is assumed to have an
>infinite number of memory cells. A Quantum Turing machine is also
>assumed to have an infinite number of potentially entangled qbits.
>The relation between any classification of problems like P or NP and a
>finite resource machine is problematic.
A real-life quantum computer having a finite number of potentially
entangled qubits behaves asymptotically like a conventional Turing
machine.
This is because having an infinite amount of memory doesn't remove the
limitation that a non-quantum Turing machine still has - the ability
to do only one thing at a time.
An infinite number of qbits, on the other hand, increases the number
of things a quantum computer can do at once, so that would affect its
asymptotic behavior. But in a way not applicable to a quantum computer
with finite resources.
Actually, the relationship between abstract classifications and finite
resource machines isn't too bad: the curve holds as long as the
problem doesn't exceed the size of available memory. And when
'available memory' changes from RAM to the hard disk, a constant
factor kicks in. (Or, of course, things can get _much_ more
complicated if one attempts to - and has the opportunity to - optimize
for things like head movement.)
So a quantum computer with lots of cheap conventional memory, but a
relatively limited number of qbits, would still behave like a regular
computer asymptotically once all the qubits were in use. (And, yes,
that wouldn't be truly asymptotic, since eventually the conventional
memory runs out too.) But that wouldn't stop it from being much
faster.
Sure, the exact relationship is complex, but there are ranges over
which the characterization of a problem as in P or NP still provides
plenty of information about what to expect even on real-world
computers.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Cool Cryptography Website!
Date: Tue, 29 May 2001 01:27:30 GMT
I just found this neat web site about cryptography.
One problem is that the pages in it about encryption are a bit far
down in the tree structure, and so you might miss them if I just give
you the URL for the top page.
So here's the URL I found first from a search engine:
http://www.cmb.ac.lk/academic/science/dscs/courses/Computer/Msc/DSandC/breaking2.htm
Of course, I do have every sympathy to hard-pressed professors,
particularly when they're working in Third World countries, but
suffice it to say that I was a bit bemused when I encountered the
pages. However, the site is still under construction (some pages are
empty), and my site is not its only source of material...
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (Bob Wandstraat)
Subject: Between Silk and Cyanide code question
Date: 28 May 2001 18:31:01 -0700
This is one of the finest written books I have ever read,
and the subject matter is riveting (running code and security for agents
sent to Europe during WWII).
But I am SO out of my depth. To wit:
When Marks wrote the dirty Yiddish word on the blackboard after the
briefing with odious Ozane, he writes (p.59):
Its twelve deadly letters were positioned at numbers
55.4.6.10.15.22.3.7.45.21.2.24 in the code groups.
>From that I get:
leoorseesell (from the top message)
useghostspin (from the bottom message)
Unfortunately, the anagram cracker at www.wordsmith.org/anagram/
doesn't have a Yiddish switch.
Can anyone help?
tia
Bob Wandstraat
Otara, New Zealand
------------------------------
Subject: Re: Quantum Computers with relation to factoring and BBS
From: [EMAIL PROTECTED] (Charles Blair)
Date: Tue, 29 May 2001 01:30:41 GMT
"Roger Schlafly" <[EMAIL PROTECTED]> writes:
>"Charles Blair" <[EMAIL PROTECTED]> wrote
>> As far as I know, it is still open whether factoring is NP-complete.
>> Thus, it is possible that there is a polynomial-time algorithm for
>> factoring (on traditional, non-quantum computers) but that there
>> is no such algorithm for things like the travelling salesman problem.
>It is also possible that there is a polynomial time algorithm for
>the traveling salesman problem.
I think we're in agreement. Let me add that a polynomial-time
algorithm for travelling salesman, or other NP-complete problems,
would imply a polynomial-time algorithm for factoring, but that the
converse is not known to hold.
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Tue, 29 May 2001 01:47:58 GMT
Larry Kilgallen wrote:
> But some of them are susceptible to cryptographic controls.
> Consider the issue of delegation. My doctor can see my
> medical records. My doctor should be able to delegate
> the ability to see those records to a specialist for a
> limited amount of time, but without delegating unlimited
> rights to further delegation.
How? Isn't this yet another attempt at DRM or am I missing something?
--
Samuel S. Paik | [EMAIL PROTECTED]
3D and digital media, architecture and implementation
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Uniciyt distance and compression for AES
Date: 29 May 2001 02:23:36 GMT
Uncity distance is a concept found by Shannon that is valid even
today. It has to do with the amount of cipher text needed to be
looked at in a ciphertext only attack to determine the key and
the rest of a secret message.
Using K of 6.8 for english ASCII K = 8 - 1.2
for 256 key cipher like Rijndael if its strong you
get Uncity distance of 256/K which is 37.8
since no compression has occured that is the amount of cipher
text one needs to look at before one can be certain of the correct
key. And in this case is the amount of plain text.
What happens if we use compression say a factor of 2
then you use K of 4 - 1.2 for K of 3.8 for a uncity
distance of 67.36 characters of cipher text before a break
can be certain. That means the plain text since a compression
factor of 2 would have had to be 134.73 characters.
But Uncity distance is based on the availablity of every key
if one has a compression factor of 2 so plain text half the
size. It does little good if nost key don't map to anything
on decompression. I can't say for certain how bad the compression
used in things like pgp but I know that for just about every
key I test it failes to decompress to anything. The question
is for a compression I described above how many keys actually
have to work I can't really use 256 for the key entropy of the
key in the unicity formula since most keys don't decrypt to
anything and can be thrown out. If I compress above
I can calculate this quite easily for text
X is 3.8 times 37.8 which is 143.64 This means that the
ture unicity distance has not changed at all if there are still
143.64 bits of key space. If there are less then the uncity
distance is actually shorter than if the file lenght had not
been compressed at all. If the key space is longer than 143.64
then we gain a little bit of Uncity distance. The key
space stays the same if bijective compression is used. However
as with all compression methods used for encyrption you
may need to whiten the front of file since compression
usually takes a while to take affect unless you condtion
the compressor first. One could use my BWT compression. Since
its affect on real key space is a direction function of lenght
of file. if file is 2**16 bytes long key space is reduced by
16. With my BWT there would be no need to whiten the file.
Note many of my compressors fully bijective the BWT is not
but is close and no whitening needed.
Any comments welcome.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 29 May 2001 03:24:43 GMT
Subject: Re: Cool Cryptography Website!
[EMAIL PROTECTED] (John Savard) writes, part:
>So here's the URL I found first from a search engine:
>
>
>http://www.cmb.ac.lk/academic/science/dscs/courses/Computer/Msc/DSandC/br
eaking2.htm
>
>the site is still under construction (some pages are
>empty), and my site is not its only source of material...
He doesn't seem to credit your site as an Internet resource.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Uniciyt distance and compression for AES
Date: Mon, 28 May 2001 18:54:50 -0800
"SCOTT19U.ZIP_GUY" wrote:
>
> Uncity distance is a concept found by Shannon that is valid even
> today. It has to do with the amount of cipher text needed to be
> looked at in a ciphertext only attack to determine the key and
> the rest of a secret message.
[snip]
Unicity distance can be interpreted as the smallest number of
of ciphertext letters which must be intercepted in order to
expect a unique, *meaningful* decipherment. It
is a function of both keyspace entropy and the redundancy of the
"language". Language redundancy arises from the fact that not
all possible messages are meaningful.
I don't see how compression makes a difference. Compression reduces
the redundancy (a message in a language that contains no redundancy
cannot be compressed), but since the redundancy is a property
of the *language* then not all decompressions will be meaningful.
I don't think you can get around this. It seems to me that all you're
doing is adding another step, i.e. decrypt and then decompress to
determine
whether or not the message is meaningful, rather than just decrypting as
the case would be if no compression were used.
Simply put, redundancy is a feature of the language. You can't change
the redundancy without changing the language. Without changing the
redundancy you can't change the unicity distance (assuming no
change in the entropy of the keyspace).
Am I overlooking something?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Uniciyt distance and compression for AES
Date: 29 May 2001 03:18:50 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in
<[EMAIL PROTECTED]>:
> Uncity distance is a concept found by Shannon that is valid even
>today. It has to do with the amount of cipher text needed to be
>looked at in a ciphertext only attack to determine the key and
>the rest of a secret message.
> Using K of 6.8 for english ASCII K = 8 - 1.2
>for 256 key cipher like Rijndael if its strong you
>get Uncity distance of 256/K which is 37.8
>since no compression has occured that is the amount of cipher
>text one needs to look at before one can be certain of the correct
>key. And in this case is the amount of plain text.
>
> What happens if we use compression say a factor of 2
>then you use K of 4 - 1.2 for K of 3.8 for a uncity
Sorry folks one beer to many it should be 8 - 2.4 for 5.6
>distance of 67.36 characters of cipher text before a break
and then for 45.71 for the new uncity distance in cipher twxt
>can be certain. That means the plain text since a compression
>factor of 2 would have had to be 134.73 characters.
like wise 91.42 plain text characters
>
> But Uncity distance is based on the availablity of every key
>if one has a compression factor of 2 so plain text half the
>size. It does little good if nost key don't map to anything
>on decompression. I can't say for certain how bad the compression
>used in things like pgp but I know that for just about every
>key I test it failes to decompress to anything. The question
>is for a compression I described above how many keys actually
>have to work I can't really use 256 for the key entropy of the
>key in the unicity formula since most keys don't decrypt to
>anything and can be thrown out. If I compress above
>I can calculate this quite easily for text
>X is 3.8 times 37.8 which is 143.64 This means that the
5.6 * 37.8 for 211.68 replace 211,68 for rest of message
>ture unicity distance has not changed at all if there are still
>143.64 bits of key space. If there are less then the uncity
>distance is actually shorter than if the file lenght had not
>been compressed at all. If the key space is longer than 143.64
>then we gain a little bit of Uncity distance. The key
>space stays the same if bijective compression is used. However
>as with all compression methods used for encyrption you
>may need to whiten the front of file since compression
>usually takes a while to take affect unless you condtion
>the compressor first. One could use my BWT compression. Since
>its affect on real key space is a direction function of lenght
>of file. if file is 2**16 bytes long key space is reduced by
>16. With my BWT there would be no need to whiten the file.
>Note many of my compressors fully bijective the BWT is not
>but is close and no whitening needed.
>
>
>
> Any comments welcome.
>
>
>
>David A. Scott
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: To prove PGP can easily be misused...
Date: Mon, 28 May 2001 22:19:18 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> If your view is that some (or even many) politicians
> are unintelligent, then you may have a point. Otherwise,
> every person, whether involved in politics or not, is
> certainly not happy when his privacy gets compromised.
> Politicians are more liable to get into headlines of
> newspapers, when certain secrets become known to the
> public. From this view, it couldn't be that 'privacy
> is their last consideration'. (It could well be that
> privacy of the common people -- not their own --
> is their last consideration, on the other hand.)
>
> M. K. Shen
People who want to parade themselves as public should put the public
first. It is not that they don't deserve private lives, it is that they
should not presume to define the private lives of others while pretending
to be creatures of virtue. What they do in the name of the public,
however, is everybody's business.
Hidden deals and brib taking are anti-democratic activities. The people
have a right to know and the press has a right to find evidence for such
travesties. Government has no right to hide truth when it reflects badly
on them, but a responsibility to talk straight about public matters, and
not to involve us in their private pubic ones, etc.
--
Suppose California quit sending food back East.
Would Gerorge be ready to barter with energy?
------------------------------
From: [EMAIL PROTECTED] (Andrew Phillips)
Crossposted-To:
comp.os.ms-windows.programmer.tools.misc,comp.os.ms-windows.apps.utilities.win95
Subject: Call for Beta Testers - HexEdit 2.1
Date: 28 May 2001 22:06:18 -0700
HexEdit 2.1 is almost ready for release and we are looking for a small
number of beta testers.
For more information on HexEdit see "About HexEdit" below.
After carefully reading the requirements below, if you're interested please
answer the questions and forward your response to [EMAIL PROTECTED]
Please send your reply before June 8th. We will reply to you by June 10th.
All information and software will be available by June 15th.
Beta Tester Requirements
========================
You need to be familiar with at least one hex editor, and have some
programming experience.
Due to new features added to this version we have particular requirements.
Note that not fulfilling these requirements will not necessarilly exclude
you.
1. At least 2^32 bytes (4 Gbytes) available space on a single drive.
(HexEdit now allows editing of files > 4 Gbytes.)
2. Experience with encryption and/or Crypto API.
(HexEdit now has encryption facilities using the Windows Crypto API.)
3. A printer for testing of new printing options.
4. Ability to download a 2 Mbyte file from the Internet.
What You Will Need To Do
========================
1. Spend a few hours testing specific features.
2. Run some test macros.
3. Proofread a section of the on-line help documentation (optional).
4. Send comments and suggestions to us.
5. Complete your testing by June 25th.
What You Will Get
=================
You will get an activation code for HexEdit 2.0/2.1 and the satisfaction
that you have contributed to making a good program better.
If you are the first to report a bug we will give you 3 HexEdit unlimited
user-licences, or any reward that you can suggest that is reasonable.
Questions
=========
What version of Windows are you running?
How much free disk space do you have (on a single drive/partition)?
How much memory do you have?
What experience do you have with hex editors?
How often would you use a hex editor?
What programming experience do you have?
Do you have any knowledge of encryption and/or the Windows Crypto API?
Do you have a printer? What sort?
Do you have multiple monitors?
Have you ever been involved in a beta test program before?
Is there any other relevant information you want to provide?
============================================================================
About HexEdit
=============
HexEdit is hex editor that is easy to use if you are used to Windows
programs like Word. It reliably edits large binary files.
It has many display and editing options like: autofit, hex/decimal
addresses, RO/RW, INS/OVR modes, font selection, increase/decrease font
size, mouse-wheel support, drag and drop, printing (including selection) and
print preview, fast (Boyer-Moore algorithm) searches and compares, clipboard
support (binary, ASCI, EBCDIC, Unicode), etc.
It can continuously display over 50 properties in a pinable dialog:
including decimal (8/16/32/64 bit values, big- or little-endian,
signed/unsigned), characters, IEEE/IBM floating point numbers etc. You can
also edit most properties, eg. to change a floating point value. You can
see characters as ASCII/ANSI, IBM/OEM (PCDOS), EBCDIC, Unicode.
There are many time-saving user interface niceties like the Find tool (with
drop-down history list) that allows quick searches for hex digits or
ASCII/EBCDIC strings, and the hex and decimal jump tools. The status bar
display such things as number of occurrences of current search string,
distance from the cursor to the "mark", RO/RW, INS/OVR, REC (macro
recording) CAPS etc. The length of the selection is available while
selecting or by pressing the SHIFT key.
Advanced features include unlimited file/window undo, background searches,
keystroke macros. A powerful (hex/dec/oct/binary - 8/16/32/64) calculator
is included that has many features (16 binary ops, 16 unary ops, memory
etc). The calculator allows file manipulation and is tightly integrated
with macros making it simple to create and repeat complex operations.
Version 2.0 added customization of toolbars, menus and keyboard. You can
create toolbars and buttons and even edit button images. Customize 6
different context menus and 3 different double-click events. All
user-defined keys appear in menus and tooltips. It also adds user-defined
tools and Windows Manager (like Visual Studio).
Version 2.1 adds the ability to edit files larger than 4 Gbyte, window tabs,
highlighter, encryption features, improved printing, and other
user-interface improvements.
------------------------------
** 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
******************************
