Cryptography-Digest Digest #768, Volume #13 Thu, 1 Mar 01 01:13:01 EST
Contents:
Re: Keystoke recorder (Benjamin Goldberg)
Re: HPRNG ("Tom St Denis")
Re: Hash strength question (Bryan Olson)
Re: How to find a huge prime(1024 bit?) ("Dik T. Winter")
Re: philosophical question? (Nicol So)
Re: Keystoke recorder (Paul Rubin)
Re: Keystoke recorder (Ben Cantrick)
Re: Keystoke recorder ("Tom St Denis")
Re: Hash strength question (Benjamin Goldberg)
Re: HPRNG (Benjamin Goldberg)
Re: Keystoke recorder (nemo outis)
Re: what is the use for MAC(Message Authentication Code ), as there can be digital
signature? ("Scott Fluhrer")
Re: how long can one Arcfour key be used?? ("Scott Fluhrer")
Re: "RSA vs. One-time-pad" or "the perfect enryption" (Steve Meyer)
Re: how long can one Arcfour key be used?? ("Tom St Denis")
Re: what is the use for MAC(Message Authentication Code ), as there can be digital
signature? (John Savard)
Re: what is the use for MAC(Message Authentication Code ), as there can be digital
signature? ("Lyalc")
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Keystoke recorder
Date: Thu, 01 Mar 2001 02:16:09 GMT
Alberto wrote:
>
> It's seems that the easiest way to access encrypted data is to gain
> access to the target computer and install such device.
>
> Have you ever seen one of them? How does it look like? How can you
> defend yourself against this kind of attack?
Along this line of questioning -- How good is the xterm "secure
keyboard" function at preventing software keystroke logging?
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Thu, 01 Mar 2001 02:16:51 GMT
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Here's an idea for a TRNG, which uses components which are used in
> Quantum Cryptography. Get a device which produces one photon at a time,
> send it through a polarizer. Follow this with a second polarizer at 45
> degree angle from the first. Photons will go through the first 100% of
> the time, and through the second exactly 50% of the time. Measure
> photon/no photon as your bit of randomness. I call the system a
> Heisenburg Random Number Generator, or HRNG. Bits might be slightly
> biased, if the mirrors aren't exactly 45 degrees apart, but they should
> not be correlated in any way, shape, or form.
Sounds very neat. Of course you could xor a few HRNG bits together to
smoothen out any bias.
Tom
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Hash strength question
Date: Wed, 28 Feb 2001 19:39:26 -0800
Benjamin Goldberg wrote:
[...]
> There's a couple of reasons I want to use XOR, though, things I don't
> get from using a hash of hashes.
>
> 1) XOR is of course much faster.
Not in the greater scheme of things. To use the construct
you have to run the hash at least twice anyway. The
single-block hash at the end doesn't dominate the time.
> 2) Suppose that the hashes produced are 128 bits in length. Now suppose
> that one bit of the input is changed. This results in one of the output
> hashes changing with (1-1/2^128) probability. If I hash the hashes, the
> odds of the final result changing are (1-1/2^128)^2. If I XOR the
> hashes, the probability of the final result changing is (1-1/2^128).
How did that make your list of things to worry about? The
theorem Scott Fluhrer posted removes the concern: if the
hash is collision resistant, then the hash of hashes is
collision resistant. The same is not true of the XOR
scheme.
Note that the XOR scheme allows a time-space tradeoff that
square-roots the time to find a preimage for a given digest.
Surely the issue in 2) is trivial.
If you think 2) is really a problem, note that a
Merkle-Damgard-shaped hash function (MD5, SHA-1, most
others) repeatedly hashes the current chaining values along
with the next block of the message to get new chaining
values. If we hash two long strings which differ only near
the start, the state has a chance to collide after each
block-compression, and if it ever does then the final
digests collide. The "problem" is very much like the issue
in 2).
--Bryan
------------------------------
From: "Dik T. Winter" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,sci.math
Subject: Re: How to find a huge prime(1024 bit?)
Date: Thu, 1 Mar 2001 03:59:32 GMT
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Free-man)
writes:
> On Wed, 28 Feb 2001 02:51:53 GMT, "Dik T. Winter" <[EMAIL PROTECTED]>
> wrote:
...
> >Well, I say it is correct. The premissa is: "there is a finite number
> >of primes". Multiplying them all together and adding 1 shows that the
> >resultant number is not divisible by any prime. Hence by the definition
> >of prime it must be prime, contradicting the premissa.
>
> Not exactly. Under that premise, it can be proved that the number
> product + 1 is not prime and not composite.
Yes, that is something else that can be proven. Taking enough time you
can probably prove that 2 is not prime. But you can also prove that the
new number is prime. Whatever contradiction you get at eventually, makes
the premissa false, and that is all that matters. A -> B is true whenever
A is false.
> >But let's analize it more completely:
> >Def: a prime is an integer number > 1 that is not divisible by any smaller
> > number, except 1.
> >Theorem: a non-prime > 1 is divisible by a prime.
> >Proof: it is divisible by a smaller number which is either prime or non-
> > prime, so by infinite descent the result holds.
> >Theorem: there is an infinitude of primes.
> >Proof:
> > Suppose there is only a finite number of primes. Multiply them all
> > together and add 1. Suppose the result is non-prime, but according
> > to the theorem above it should be divisible by a prime, but none of
> > the primes fit, so it is prime. A contradiction, we have found a
> > new prime.
>
> No, because you have two "suppose"
Yes, so what? The second "suppose" is immediately refuted, so only one
"suppose" remains.
> >
> >The confusion is that the new number is indeed not necessarily prime, but
> >when the premissa is "a finite number of primes" we just showed that the
> >number *is prime*,
>
> No, it is shown that the number is not prime and not composite.
That entirely depends on how you are wording the stuff. In my wording
above I showed that the new number is prime. By the theorem it can't
be composite (non-prime) because it is not divisible by a smaller prime,
so it must be prime.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: philosophical question?
Date: Wed, 28 Feb 2001 23:13:16 -0500
Reply-To: see.signature
Peter Osborne wrote:
>
> Is randomness a kind of information ?
> Is it the highest density of information (that we are not able to
> understand)?
> Is it merely the opposite of information?
To understand the relationship between randomness and information, it
would be helpful to have some useful definitions for the terms involved.
For our purpose, I would define randomness as the inherent
unpredictability of something (a phenomenon or the outcome of some
process). Information can be defined as the reduction in uncertainty
(about something).
The amount of information (about some X) conveyed by a signal is the
amount by which it reduces the uncertainty on the part of the observer
about X. A signal that lets you know about something highly predictable
has little information because there is little uncertainty to begin with
(and little room for uncertainty reduction). A signal that lets you know
about something maximally random carries the maximum amount of
information.
A sequence of equiprobable symbols carries the maximum amount of
information if you view the value of the symbols to be the "something"
whose uncertainty is reduced by seeing the symbols.
> Can there be a fundamental difference between pseudo-randomness and
> real randomness (e.g. generated by radioactive decay or thermal
> noise), especially under these aspects mentioned above?
There is a qualitative difference between randomness and
pseudorandomness. The concept of pseudorandomness involves limitations
on the observer. Something is pseudorandom to an observer if the
observer cannot tell it apart from something truly random with good
success. So something may be pseudorandom to one observer but very
predictable to another.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Keystoke recorder
Date: 28 Feb 2001 20:17:22 -0800
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> Along this line of questioning -- How good is the xterm "secure
> keyboard" function at preventing software keystroke logging?
The idea is the attacker gains access to the target computer.
At that point they can change the X server to log keystrokes.
Do you ever wonder if ALL pc hardware will soon have backdoors
for law-enforcement access, if they don't already?
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: Keystoke recorder
Date: 28 Feb 2001 21:21:06 -0700
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>Alberto wrote:
>> It's seems that the easiest way to access encrypted data is to gain
>> access to the target computer and install such device.
>>
>> Have you ever seen one of them? How does it look like? How can you
>> defend yourself against this kind of attack?
>
>Along this line of questioning -- How good is the xterm "secure
>keyboard" function at preventing software keystroke logging?
From the xterm man page:
=====
SECURITY
X environments differ in their security consciousness.
Most servers, run under xdm, are capable of using a
``magic cookie'' authorization scheme that can provide a
reasonable level of security for many people. If your
server is only using a host-based mechanism to control
access to the server (see xhost(1)), then if you enable
access for a host and other users are also permitted to
run clients on that same host, there is every possibility
that someone can run an application that will use the
basic services of the X protocol to snoop on your activi-
ties, potentially capturing a transcript of everything you
type at the keyboard. This is of particular concern when
you want to type in a password or other sensitive data.
The best solution to this problem is to use a better
authorization mechanism that host-based control, but a
simple mechanism exists for protecting keyboard input in
xterm.
The xterm menu (see MENUS above) contains a Secure Key-
board entry which, when enabled, ensures that all keyboard
input is directed only to xterm (using the GrabKeyboard
protocol request). When an application prompts you for a
password (or other sensitive data), you can enable Secure
Keyboard using the menu, type in the data, and then dis-
able Secure Keyboard using the menu again. Only one X
client at a time can secure the keyboard, so when you
attempt to enable Secure Keyboard it may fail. In this
case, the bell will sound. If the Secure Keyboard suc-
ceeds, the foreground and background colors will be
exchanged (as if you selected the Reverse Video entry in
the Modes menu); they will be exchanged again when you
exit secure mode. If the colors do not switch, then you
should be very suspicious that you are being spoofed. If
the application you are running displays a prompt before
asking for the password, it is safest to enter secure mode
before the prompt gets displayed, and to make sure that
the prompt gets displayed correctly (in the new colors),
to minimize the probability of spoofing. You can also
bring up the menu again and make sure that a check mark
appears next to the entry.
=====
In other words, you only need it if you're dumb enough to do
"xhost +". It will only protect you while it's enabled, and while
it's enabled you won't be able to use any other window. It protects
you only from snooping at the X11 protocol level, and won't do a damn
thing against lower-level software snoopers. Nothing I've ever seen
will stop a hardware keyboard logger.
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
Don't look back; the lemmings are gaining on you.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Keystoke recorder
Date: Thu, 01 Mar 2001 04:21:33 GMT
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> > Along this line of questioning -- How good is the xterm "secure
> > keyboard" function at preventing software keystroke logging?
>
> The idea is the attacker gains access to the target computer.
> At that point they can change the X server to log keystrokes.
>
> Do you ever wonder if ALL pc hardware will soon have backdoors
> for law-enforcement access, if they don't already?
Yeah, let's all be paranoid cuz it's cool to phreak. Gee get a life man.
Tom
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Hash strength question
Date: Thu, 01 Mar 2001 04:27:09 GMT
Bryan Olson wrote:
>
> Benjamin Goldberg wrote:
> [...]
> > There's a couple of reasons I want to use XOR, though, things I
> > don't get from using a hash of hashes.
> >
> > 1) XOR is of course much faster.
>
> Not in the greater scheme of things. To use the construct
> you have to run the hash at least twice anyway. The
> single-block hash at the end doesn't dominate the time.
The multiple hashes are run in parrallel on seperate chips.
Thus, if we are recieving data very fast, X times faster than we can
ordinarily hash it, then by using X hashing chips, each of which
recieves every Xth byte of the stream, we can hash as fast as we recieve
the stream, even though the hash chips are very slow.
However, except for that, I guess I have to agree with you on all your
other points.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Thu, 01 Mar 2001 05:21:56 GMT
Tom St Denis wrote:
>
> "Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Here's an idea for a TRNG, which uses components which are used in
> > Quantum Cryptography. Get a device which produces one photon at a
> > time, send it through a polarizer. Follow this with a second
> > polarizer at 45 degree angle from the first. Photons will go
> > through the first 100% of the time, and through the second exactly
> > 50% of the time. Measure photon/no photon as your bit of
> > randomness. I call the system a Heisenburg Random Number Generator,
> > or HRNG. Bits might be slightly biased, if the mirrors aren't
> > exactly 45 degrees apart, but they should not be correlated in any
> > way, shape, or form.
>
> Sounds very neat. Of course you could xor a few HRNG bits together to
> smoothen out any bias.
Or use your measurement of the bias to adjust your polarizers, or use an
(adaptive?) arithmetic coder to eliminate/decrease the bias, or feed the
data to Yarrow giving an entropy estimate of the stream based on how
much bias there is, etc. Lots of ways to reduce bias.
Also, the decorrelation method of discarding 00 and 11, and converting
01 and 10 to 0 and 1 should remove all bias. Too bad this cuts the
bitrate by about 75% for unbiased data, slightly more for slightly
biased data.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: [EMAIL PROTECTED] (nemo outis)
Subject: Re: Keystoke recorder
Date: Thu, 01 Mar 2001 05:29:10 GMT
To respond to only one of the many interesting points you raise, I daily do an
MD5 hash of every executable and near-executable (dll, vxd, etc.) on my system
and compare them to "known-good" values. (Also look for new or deleted ones!)
Takes about 15 minutes on my 20-gig drive (just right for enjoying that first
cup of coffee). The hash program and the known-good values are on a (securely
stored) encrypted CD.
This is a very effective method unless/until the OS and major programs have
backdoors built into them. But that's what's meant by trust models and why
known-good was in quotation marks :-)
Regards,
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Alberto wrote:
>
>> It's seems that the easiest way to access encrypted data is to gain
>> access to the target computer and install such device.
>
>The best place to see encrypted data is at the end points, before it is
>encrypted or after it is decrypted. Running my program implementing my
>intent on the target's system with the target's privileges is a good way
>to do that. If you are persistently connected to the Internet, it is
>almost as good as being you. That is why the FBI is asserting the right
>to break into your home or office for the purpose of installing such
>software. It should be noted to their benefit, that in the cases where
>they admit to having done this already, they have obtained a warrant.
>Notice that this is very different from a warrant that is served on you
>and that you know about. They have also suggested that they do not
>really need a warrant.
>
>> Have you ever seen one of them? How does it look like? How can you
>> defend yourself against this kind of attack?
>>
>> Thanks.
>> Alberto
>
>Both Back Orifice and SubSeven not only permit the monitoring of your
>key strokes, they facilitate doing it in real-time. They are not
>impossible to detect but they are far from obvious. Simply running them
>under another name would make them less obvious but they could be far
>more covert than they are. If one wanted to be really covert, one would
>insert this functionality into a copy of the operating ystem and run it
>under the operating systems identity but simply running it as an
>extension or a common application would be good enough. If the FBI
>breaks into your house or office, installing these is trivial as is
>monitoring you when you are on the Internet. Getting you to install it
>yourself is as easy as saying, "Click here to install the latest version
>of RealPlayer" if only not so accurately aimed. I guarantee you Hanssen
>would click on any mail attachment whose name was in the Cyrillic
>alphabet. Obviously, the FBI is disingenuous when they assert that the
>use or strong crypto results in perfect security for terrorists, drug
>dealers, spies, hackers, and pornographers.
>
>One protects oneself from this kind of attack with great care, not to
>say difficulty. One should run one's system in a stand-alone
>configuration. One must exercise strict control over the content of
>one's system. Single-user single-application systems help. If you are
>a Russian spy, you should put your system in that kind of configuration
>when dealing with your communications to your handlers. One should
>reconcile what is running on one's system to what one thinks one is
>running. One should be very careful not to take the bait. One should
>run only software obtained from trusted sources in trusted packaging.
>One should run one's system in a burglar resistant burglary evident
>environment.
>
>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: what is the use for MAC(Message Authentication Code ), as there can be
digital signature?
Date: Wed, 28 Feb 2001 21:27:48 -0800
david Hopkins <[EMAIL PROTECTED]> wrote in message
news:IHgn6.4605$[EMAIL PROTECTED]...
> Thank you.
> So at present , is it still useful?
> (make a digital signature will take less than 2 second at present)
A digital signature that takes "less than 2 seconds" is not particularly
useful if you have an encrypted connection with another computer where you
exchange thousands (or millions) of messages per second, and you want to be
able to authenticate each message. You can do this with MACs.
>
> "Anton Stiglic" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > david Hopkins wrote:
> > >
> > > Why use for MAC(Message Authentication Code ),
> > > as there can be digital signature?
> > >
> > > thanks
> >
> > Because MACs are typically much faster to compute.
> > Same kind of tradeoff like between symmetric
> > encryption schemes and public key encryption schemes.
>
>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: how long can one Arcfour key be used??
Date: Wed, 28 Feb 2001 21:33:47 -0800
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:pian6.257721$[EMAIL PROTECTED]...
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:97j936$vvt$[EMAIL PROTECTED]...
> >
> > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > news:jW8n6.257260$[EMAIL PROTECTED]...
> > >
> > > "Julian Morrison" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >> Also, does anyone know how this varies with key length and
> > > > >> number-of-mixes (N in CipherSaber-2)?
> > > > > Is 'number-of-mixes' the number of passes you do during key setup
> > (with
> > > > > 1 being standard RC4)?
> > > >
> > > > Yes.
> > > >
> > > > > If so, then no, that has no effect.
> > > >
> > > > Ok. How about key length? One of my intended algorithms will use
> > throwaway
> > > > from-scratch DH to setup a key, but creating DH primes for a full
> length
> > > > 256 byte RC4 key would take several minutes a pop, way too slow.
(I'm
> > > > doing it this way so as to have "forward security" - once the
> > transaction
> > > > is over, there should be no way to decrypt it from wiretap records
and
> a
> > > > siezed machine.)
> > >
> > > RC4 can't possibly use keys bigger then 1684 bits in length. So using
a
> > > 256-byte key while "amazing" is actually quite useless. The
intelligent
> > > thing todo is to SHA256/TIGER192/MD5128/etc your DH secret and use
that
> as
> > a
> > > key into RC4.
> > >
> > > > For example, CipherSaber suggests a 62 byte key + IV; for how long
> could
> > > > that be used?
> > >
> > > The length of the key is irrelevent. A small key makes brute force
> easier
> > > but once you pass 64 bits it becomes virtually impossible to perform
the
> > > task.
> > I'm sure Tom knows, but to emphesize: that's 64 bits of entropy, not an
> > arbitrary 64 bits. 64 bits which makes up a 8 letter dictionary word is
> > quite easy to brute force if the attacker guesses that's what you did.
>
> Agreed. Of course putting ASCII into RC4 directly is a "dumb" idea. It
> severely cripples the key generation process.
Do you have a reference to that?
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Steve Meyer)
Subject: Re: "RSA vs. One-time-pad" or "the perfect enryption"
Reply-To: [EMAIL PROTECTED]
Date: 1 Mar 2001 06:00:48 GMT
On Mon, 19 Feb 2001 05:03:43 GMT, Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Steve Meyer wrote:
>> I am not sure but there may be another class. Namely, cryptography
>> in which the encryption and decryption methods are kept secret.
>
>We don't worry much about those, because often enough in practice
>there will be ways of finding out which system was used. Thus
>Kerckhoff's dictum: the secrecy of an encryption system must not
>depend on lack of knowledge of the general system, but resides in
>the lack of knowledge of the specific key. (We could add that it
>should also not depend on lack of knowledge about the plaintext
>characteristics.) By the way, the general process of figuring out
>what system was used via analysis of message properties is called
>"cryptodiagnosis".
<snip - I am working on reply. I am not sure how Rabin's provably
secure random stream method effects my argument.
>It will be interesting to see your argument. I know of no
>evidence that this was a factor. If you turn the question
>around and ask, why did workers for government cryptologic
>organizations get there first, an obvious answer would be:
>They had more experience, more support, and more at stake.
I do not think they did, i.e. only evidence seems to be popular book
(see my rump talk).
>
>Note that I've been arguing that P?=NP is not very important
>in practical cryptology.
If p==np, how can there be two way trap door functions?
I just uploaded my rump talk submission and slide to IACR E archive.
Paper title is: 'Argument for "secret encryption method" cryptography.'
Name of file is secret-encrypt-method.ps. Postscript file is also
avoilable at ftp://ftp.pragmatic-c.com in directory papers. File
name is same.
--
Steve Meyer
Pragmatic C Software Corp.
Email: [EMAIL PROTECTED]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: how long can one Arcfour key be used??
Date: Thu, 01 Mar 2001 05:52:37 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:97knf5$66h$[EMAIL PROTECTED]...
> > Agreed. Of course putting ASCII into RC4 directly is a "dumb" idea. It
> > severely cripples the key generation process.
>
> Do you have a reference to that?
Well it's obvious since the key is directly used in updating the "y"
parameter in the key gen. If the value added to "y" is limited to 32-127
then it can't work as well as if it wasn't limited at all.
No, I don't have an exact attack but I feel better using a hash on ascii
passphrases first. It concentrates the entropy better (in theory) and
avoids the potential weakness.
Tom
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: what is the use for MAC(Message Authentication Code ), as there can be
digital signature?
Date: Thu, 01 Mar 2001 05:52:32 GMT
On Wed, 28 Feb 2001 19:41:53 GMT, "david Hopkins"
<[EMAIL PROTECTED]> wrote, in part:
>Why use for MAC(Message Authentication Code ),
>as there can be digital signature?
Without a MAC, a digital signature would have to be a public-key
encipherment (or, rather, a private-key encipherment) of the entire
message. With a MAC, just the MAC needs to be enciphered to sign a
long message.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: what is the use for MAC(Message Authentication Code ), as there can be
digital signature?
Date: Thu, 1 Mar 2001 17:05:34 +1100
some debug code I have is generating and re-verifying MAC-based electronic
signatures at the rate of 100/second on a P100. Try that with digital
certificates.
Lyal
david Hopkins wrote in message ...
>Thank you.
>So at present , is it still useful?
>(make a digital signature will take less than 2 second at present)
>
>"Anton Stiglic" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> david Hopkins wrote:
>> >
>> > Why use for MAC(Message Authentication Code ),
>> > as there can be digital signature?
>> >
>> > thanks
>>
>> Because MACs are typically much faster to compute.
>> Same kind of tradeoff like between symmetric
>> encryption schemes and public key encryption schemes.
>
>
------------------------------
** 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
******************************
