Cryptography-Digest Digest #307, Volume #11 Sun, 12 Mar 00 00:13:01 EST
Contents:
RSA as symmetric algorithm (antirez)
Re: Concerning UK publishes "impossible" decryption law (JimD)
Re: Q: Voice encryption (JimD)
Re: How does % operator deal with negative numbers? (Dr John Stockton)
Re: ZIP format is gone in the past. ([EMAIL PROTECTED])
Re: sci.crypt Cipher Contest Web Site ("Adam Durana")
Re: Excel password remover (Withheld)
Re: sci.crypt Cipher Contest Web Site (antirez)
Re: Mark Twain's advice for Markku J. Saarelainen (Guy Macon)
Re: sci.crypt Cipher Contest Web Site ("Adam Durana")
Re: sci.crypt Cipher Contest Web Site ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: antirez <[EMAIL PROTECTED]>
Subject: RSA as symmetric algorithm
Date: Sat, 11 Mar 2000 21:33:26 GMT
What happen if I use RSA as symmetric algorithm?
When the attacker knows the public key RSA
security is related to the fact that the attacker is
unable to factorize N. Even if there are no proofs
this seems more solid that the normal strength
paradigm of the common block ciphers, since if
there is a way to obtain the message without
factorize N this way can be used as a fast
factorialization method. And if the public key
is not available? The fast way to break RSA is
the brute force (i.e. try all the N)?
If this is the case I guess that if before to
encrypt the message M with RSA I encrypt it with
a belived strong block algoritm like 3DES it's
really hard for the attacker to cryptanalize
this scheme. What do you think about this?
I fear this is a FAQ, in this case sorry.
--
antirez
email: antirez@linuxcare dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JimD)
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Re: Concerning UK publishes "impossible" decryption law
Reply-To: JimD
Date: Sat, 11 Mar 2000 22:02:15 GMT
On Sat, 11 Mar 2000 08:22:28 GMT, [EMAIL PROTECTED] (Lincoln Yeoh)
wrote:
>How about you booby trap your computer and tell them NOT to touch your
>computer. They touch it and poof everything melts to slag, then it's not
>your problem, as you already told them NOT to touch it.
I like that. After you've finished with the computer for the day, have
a switch which connects the case to the live side of the supply and
have lots of earthed (grounded) metal in the vicinity. Arrange it so
that the computer melts and takes the Pig with it!
--
Jim Dunnett.
dynastic at cwcom.net
Exiled in Somerset
Right at the heart of England's BSE Industry.
------------------------------
From: [EMAIL PROTECTED] (JimD)
Subject: Re: Q: Voice encryption
Reply-To: JimD
Date: Sat, 11 Mar 2000 22:02:18 GMT
On Sat, 11 Mar 2000 12:30:14 GMT, "Tom St Denis" <[EMAIL PROTECTED]> wrote:
>
>JimD <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> On Fri, 10 Mar 2000 20:03:50 +0100, Mok-Kong Shen
><[EMAIL PROTECTED]>
>> wrote:
>>
>> >For voice encryption, there are analog scramblers and digital
>> >scramblers. Is there anything against using both with the
>> >expectation of obtaining a higher security or does one use in
>> >fact both in practice? What are the algorithms used in the
>> >common types of digital voice scramblers? Thanks.
>>
>> Digital ciphony gives better quality and is much more secure, given
>> that the (stream) cipher it uses is well designed, and provided that
>> you have the bandwidth to transmit it.
>>
>> Analogue ciphony depends on splitting the audio bandwidth into
>> discrete bands and transposing these bands within the telephone
>> bandwidth according to a key. There are other schemes. See Kahn,
>> 'The Codebreakers' for an interesting examination of analogue ciphony.
>>
>> Digital ciphony samples the amplitude of the analogue audio waveform
>> at a high rate (8 kHz or more) and converts these samples to a binary
>value.
>> The binary output can then be XOR-ed with a key stream to produce a
>> pseudo-random cipher output. The process is reversed at the receiving
>> end: cipher stream is XOR-ed with the identical key stream to reproduce
>> the deciphered digital samples, which then go through a digital to
>> analogue converter to end up as (hopefully!) the original audio.
>>
>> There is a third type: a vocoder, but that's another story.
>
> I don't follow. A Vocoder is a codec that models the vocal tract for
>higher compression ratios over waveform coders. How is that an encryption
>technique?
In itself it isn't. You encrypt the vocoder output in the same way
as you would a digital one. You end up with appallingly bad quality
but you save on bandwidth. You can fit one (just) into 4 kHz.
--
Jim Dunnett.
dynastic at cwcom.net
Exiled in Somerset
Right at the heart of England's BSE Industry.
------------------------------
From: Dr John Stockton <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.javascript
Subject: Re: How does % operator deal with negative numbers?
Date: Sat, 11 Mar 2000 17:56:12 +0000
JRS: In article <[EMAIL PROTECTED]> of Sat, 11 Mar
2000 14:22:58 in news:comp.lang.javascript, Daniel James
<[EMAIL PROTECTED]> wrote:
>There's been lengthy thread on the bahaviour of the C/C++ % operator in
>comp.lanf.c++.moderated in the last couple of weeks.
>
>In that thread Andrew Koenig posted the following:
>----
>[snip]
>
> Is it desirable that (-a)/b == -(a/b) ?
>
> Is it desirable that (a/b)*b + (a%b) == a ?
>
>If the answer to both these questions is yes, then a%b has to be <=0
>when a<=0. That is, we could add a third question:
>
> Is it desirable that (a%b)>=0 whenever b>=0?
>
>and the answer would also be yes. The problem is that all three questions
>cannot have yes answers at the same time, so you have to choose which
>one will be answered no.
>
>A long time ago, Dennis Ritchie decided that the right answer to
>these questions is ``whatever the hardware gives you.'' And, as it
>happens, all division hardware I've seen gives the remainder the sign
>of the dividend, not the divisor.
That appears based on an earlier incorrect assumption : that there
should be only one MOD operation. In fact, the answer to all three
questions needs to be yes; but not simultaneously. In any practical
case, no more than two of those can be needed.
There are two possible functions Z=F(X, Y) of this sort; and their
graphs for Y=4 look like
X=0
|
/| /| /| /| /| /| /| This is the one I usually want.
/ | / | / | / | / | / | / | / It can easily be X-reversed,
|/ |/ |/ |/ |/ |/ |/ F(-X, Y).
--------------0-------------- Z=0
X=0
|
|\ |\ |\ | /| /| /| This is the one I get; one can
\ | \ | \ | \ | / | / | / | / easily invert it, Y-F(X, Y).
\| \| \| \|/ |/ |/ |/
--------------0-------------- Z=0
Sometimes the first is needed, sometimes the second is needed, sometimes
X>=0.
The real questions are :
(1) "Which is the function that % or MOD should give"? Ideally, I'd say
the first; but the second is too traditional to change.
(2) "What should the other one be called"? It really does not much
matter.
(3) and only then, "what should they each do for Y<0" - to which the
answer must be that it depends on the application, and a good software
system will make all possibilities readily and efficiently available,
either/or as operators, inline pseudo-functions (cf. Abs), or library
functions.
--
� John Stockton, Surrey, UK. [EMAIL PROTECTED] Turnpike v4.00 MIME. �
<URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ;
<URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ZIP format is gone in the past.
Date: 11 Mar 2000 14:20:44 -0800
In article <8ab43o$5o8$[EMAIL PROTECTED]>,
finecrypt <[EMAIL PROTECTED]> wrote:
>"data" in our terminology) you need at least decompessing software. And if
>you did encrypt your zip archive (not with WinZip of course :)) you also
>need decrypting software.
If reading a compressed document requires me to run an untrusted
executable, I won't do it. ZIP files can be decompressed with my own
software which I do trust. Documents should NEVER be executable unless
that's absolutely necessary - the potential for virus and trojan
transmission is too great. Furthermore, self-extracting packages only
work on the architecture that created them - which works fine if you only
ever communicate with PC users, but is completely laughable in the
heterogeneous Real World.
--
Matthew Skala "Ha!" said God, "I've got Jon Postel!"
[EMAIL PROTECTED] "Yes," said the Devil, "but *I've* got
http://www.islandnet.com/~mskala/ all the sysadmins!"
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Sat, 11 Mar 2000 18:25:27 -0500
> Agreed, to select an algorithm with in mind the most critical speed
> usage seems strange. I think that the main use of the AES finalist
> will be file encryption, email encryption and so on. For all this
> uses maybe that even an algorithm ten times more slow than 3DES
> isn't a problem and, since the speed of personal computers will be
> higher in the near future, will be every day less a problem.
> Sure, we need even an algorithm that is good for very fast links.
> For this there are a lot of good algorithm, like blowfish or some
> vertical algorithm tought only for fast link encryption.
> Somebody can reply that the security of the algorithm isn't related
> with the speed, but seems is a truth that for example a feistel
> network with a lot of rounds is more resistant to some attack.
Actually I'm willing to bet the number of applications involving
communications using AES will be greater than the ones using AES to encrypt
files and etc. Eventually (and hopefully) all traffic over the internet
will be encrypted, and people are more concerned about their data being safe
when its going over a public network such as the internet than when its
sitting on their computers at home. If you read the original paper on
Blowfish, it says that Blowfish wouldn't be practical in situations where
keys would be switched often, such as communication links. Anyone could
design a secure cipher if they used 1000 round. If your cipher requires
1000 rounds to be secure then you've designed a bad cipher.
------------------------------
From: Withheld <[EMAIL PROTECTED]>
Subject: Re: Excel password remover
Date: Sat, 11 Mar 2000 11:52:44 +0000
Reply-To: Withheld <[EMAIL PROTECTED]>
Not sure about Office 97. For Office95 you can get a password cracker
from the internet. It will return the password for an Excel95 workbook
in about 2 seconds.
They also offer a product to return Office97 passwords. I forget the
URL, but i've seen the software at work. It makes a total mockery of the
"security"
In article <6sBx4.922$[EMAIL PROTECTED]>, John E. Kuslich
<[EMAIL PROTECTED]> writes
>What you are referring to is the Write protection that may be applied to
>worksheets. I do not think you have the capability to recover the file
>level password protection. This password protection for Office 97 and
>beyond is quite sophisticated and as far as I know is only cracked by brute
>force password or key search. The encryption at the file level uses MD5
>hash and RC4. The key search is the only way to recover files that have
>well chosen, long passwords.
>
>I am correct, no??
>
>JK http://www.crak.com Password Recovery Software
>
>
>Tobiass Mai <[EMAIL PROTECTED]> wrote in message
>news:89u6s8$f10$[EMAIL PROTECTED]...
>> Hello!
>>
>> I've written a program which removes the protection of
>> Excel-workbooks/-sheets.
>> Can anybody tell me if i can get in trouble with Microsoft?
>>
>> Regards
>> Tobiass
>>
>>
>
--
Withheld
------------------------------
From: antirez <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Sun, 12 Mar 2000 00:53:56 GMT
In article <bwAy4.4114$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
> Actually I'm willing to bet the number of applications involving
> communications using AES will be greater than the ones using AES to
encrypt
> files and etc. Eventually (and hopefully) all traffic over the
internet
> will be encrypted, and people are more concerned about their data
being safe
In this context the speed is important, but not _so_ important.
What I mean is that even a quite slow algorithm like 3DES seems
enough fast for a normal troughput. Ad since it's realistic that
every host will encrypt its own traffic a gateways that links
high bandwidth networks will not encrypt nothing.
But this isn't the point, read below.
> when its going over a public network such as the internet than when
its
> sitting on their computers at home. If you read the original paper on
> Blowfish, it says that Blowfish wouldn't be practical in situations
where
> keys would be switched often, such as communication links. Anyone
No, what somebody quoted was that some lan tecnology are so fast
that a slow algorithm is really a problem: for a link to link encryption
blowfish is just prefect since the key is fixed. Anyway if the problem
of the speed is so important maybe we need two encryption standard.
Two algoritms aren't "a vertical algorithm for every application", but
just a very fast and belived secure algorithm and a quite fast
belived secure algorithm that will be probably more resistant to
some unknown cryptoanalisys tool since, for exaple, some not so fast
trick was added.
could
> design a secure cipher if they used 1000 round. If your cipher
requires
> 1000 rounds to be secure then you've designed a bad cipher.
Good point. If even a stupid is able to design a secure algorithm
usign 1000 rounds I may think that the best cryptographers of the
world will be able to build a 64 rounds algorithm that is probably
unbreakable for many and many years.
A solution can be to use an algorithm with a variable number
of rounds. For example twofish-128 for very-sensitive not-speed-critical
encryption, twofish-64 for bla bla and so on.
In a word: speed is important, but when speed is no critical I'm
unable to understand why not use a probably more secure variant.
--
antirez
email: antirez@linuxcare dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: alt.politics.org.cia
Subject: Re: Mark Twain's advice for Markku J. Saarelainen
Date: 11 Mar 2000 21:55:52 EST
In article <xmjy4.11105$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Thomas Keske) wrote:
>
>>
>> "Better to remain silent and though a fool,
>> than to speak up and remove all doubt"
>>
>
>Frankly, I don't think that the man is a fool, I think
>he's playing a game.
>
>The CIA hates newsgroups. They don't want a place
>where disgruntled ex-employees could get a forum
>and broadcast something to thousands of people that
>they aren't supposed to hear.
>
>So, the goal is to drive everybody away with the
>impression that only crazies would bother posting
>here.
They sure are doing a fine job of it!! :)
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Sat, 11 Mar 2000 23:09:58 -0500
> In this context the speed is important, but not _so_ important.
> What I mean is that even a quite slow algorithm like 3DES seems
> enough fast for a normal troughput. Ad since it's realistic that
> every host will encrypt its own traffic a gateways that links
> high bandwidth networks will not encrypt nothing.
> But this isn't the point, read below.
Actually there are many routers that provide encrypted tunneling, and even
with every host doing thier own encrypting, sending a gigabyte of data will
still be slow if you use something like 3DES.
> > when its going over a public network such as the internet than when
> its
> > sitting on their computers at home. If you read the original paper on
> > Blowfish, it says that Blowfish wouldn't be practical in situations
> where
> > keys would be switched often, such as communication links. Anyone
>
> No, what somebody quoted was that some lan tecnology are so fast
> that a slow algorithm is really a problem: for a link to link encryption
> blowfish is just prefect since the key is fixed. Anyway if the problem
> of the speed is so important maybe we need two encryption standard.
> Two algoritms aren't "a vertical algorithm for every application", but
> just a very fast and belived secure algorithm and a quite fast
> belived secure algorithm that will be probably more resistant to
> some unknown cryptoanalisys tool since, for exaple, some not so fast
> trick was added.
Well yes if the key is not changed frequently Blowfish is fine. I said when
the key is changed frequently Blowfish would not be practical. SSH includes
Blowfish as one of its ciphers, so it does do fine when the key does not
change often. In some communication systems, keys are not saved or they are
changed very frequently. Systems like these would need an algorithm with
fast key scheduling. Blowfish's key scheduling process is pretty slow
compared to other algorithms. =)
> could
> > design a secure cipher if they used 1000 round. If your cipher
> requires
> > 1000 rounds to be secure then you've designed a bad cipher.
>
> Good point. If even a stupid is able to design a secure algorithm
> usign 1000 rounds I may think that the best cryptographers of the
> world will be able to build a 64 rounds algorithm that is probably
> unbreakable for many and many years.
> A solution can be to use an algorithm with a variable number
> of rounds. For example twofish-128 for very-sensitive not-speed-critical
> encryption, twofish-64 for bla bla and so on.
> In a word: speed is important, but when speed is no critical I'm
> unable to understand why not use a probably more secure variant.
People have mentioned variable rounds before and its a good idea.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Sun, 12 Mar 2000 04:45:10 GMT
In article <8aepr4$2ur$[EMAIL PROTECTED]>,
antirez <[EMAIL PROTECTED]> wrote:
>
...
> A solution can be to use an algorithm with a variable number
> of rounds. For example twofish-128 for very-sensitive not-speed-
critical
> encryption, twofish-64 for bla bla and so on.
> In a word: speed is important, but when speed is no critical I'm
> unable to understand why not use a probably more secure variant.
>
> --
> antirez
> email: antirez@linuxcare dot com
>
I think this discussion is missing the point. Security is assumed in
the AES finalist. So far as anybody knows, none of them have a
shortcut. Speed is a secondary criteria. If two algorithm are equally
secure then why not take the faster one. As a parallel, why use bubble
sort when split sort is available?
Lets remember that no realistic attack has ever been found on DES.
Serpent, Rijndael, Twofish, Mars and RC6 all appear -stronger- than
DES. Why run 64 rounds when 20 is secure? Anyway the weakness of most
security system is not the cryptography. If you want to eavesdrop,
planting a keyboard recorder is much easier.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
