Cryptography-Digest Digest #912, Volume #9 Mon, 19 Jul 99 20:13:03 EDT
Contents:
BLT solutions (wtshaw)
Re: Storing RSA public/private keys ("Thomas J. Boschloo")
Re: another news article on Kryptos (Dave Salovesh)
Re: why is it that nowadays people have to protect their conversations (Greg)
Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram) (John Savard)
Re: another news article on Kryptos (Mr. Kile A. Noy)
Re: Length of public key in PGP? ([EMAIL PROTECTED])
Re: Benfords law for factoring primes? ("Thijs vd Berg")
Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram) (John McDonald, Jr.)
Re: NBE: Not crackable by brute force key search (Greg)
Re: NBE: Not crackable by brute force key search (Greg)
Re: Compression and security (was: Re: How to crack monoalphabetic ciphers) (Sundial
Services)
Re: Length of public key in PGP? ([EMAIL PROTECTED])
Re: Does base64 encoding lessen security? (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: BLT solutions
Date: Mon, 19 Jul 1999 15:45:18 -0600
Here are four keys from the posting I made a couple of weeks ago:
1) Alpha(BLT): switzerla ndbycog/f hjkmpquvx
2) Alpha(BLT): /cukdreps nfqjvlgzo mwhbtxayi
3) Alpha(BLT): wkemarjft xbodnpuyv gcshzqi/l
4) Alpha(BLT): mxtuacoyv dzeq/wkln jbirfgphs
At the time, key one was hand deduced from "switzerland by cog"
I spent a few minutes just now and fixed the application to where it can
easily make completed alphabet key from entered text, in addition to hash
and direct entry options. This is particularily handy for those
interested in recreation ciphers.
For example, source UNITED STATES OF AMERICA would render the following
completed alphabet key: Alpha(BLT): unitedsao fmrc/bghj klpqvwxyz
The fun way to solve BLT seems to be to have two ciphertexts from the same
plaintext, so that you can quickly work out which letters are in each of
the three sets.
I leave it to anyone who wants to solve the following pair of ciphertexts
for the completed alphabet key:
hrobq ztvzi cyblh aqjfm uksln vjifr klexg tahbk icudh kyulg tqgth kgmwf
qefdt madbi atdxu xykqj stzat yxekp cvgkg zwmsw mjqun cvirt ktmun xyvpd
ovmmy dfusk qgdrm swury fkrqu mgjim gyddo tftgg wdkem pyodu asmqq ougok
sjtse jfmbz tuzvy vgilm vgled pazte gvhhb namyq jdrfy woqfi yxhvt gptgv
wfsdx czmxm gfkhl tsnqr cmlkt uahzs lrqdk evycr onvme fjvsz dbkna rbcjb
xbtgn dtfoe xlbrt kbtgf tvonm lktdy qxklv ttrjz gxlwv hcakc sxmss tyqvu
dguxb ddfgl itrbf svrjq zfciv tztun fsrqf ubkxr ovqyl uarow qakcc grvmn
xcvfg jaybv xjvfe lmcfy iwbqh ieqzv blfsa ivhpb ykswv rhtdx aylqf pmpwb
qcisl hvapd fixaw leaml krdzd fihsd gyqsz nfqcl rhhxs yhkqy jylqu vccym
tsblc bcylb kusbm vgrvi zkhul uowxd tosks lylvx qaegi qmfkv mqblg vjsrh
qmzrm fgmuk ezaqj wdktm eaomq akomf svrxe vmyql kuesb jkygb dkgda ubate
flifi sltyg btylb vrjbl ayqin xatnq vrirm vkazy ovwdz dwmgm vtpsq tlbxt
xfcgw bkpvf bcqdu frsgb hfgrt nptku stkdb udqtg apmxd tiaxb qkydv yzvtc
dkfrl qvxsk qgrms horyk pedhf wabmh ahykt ofldh zdxws dfoge dgbqb yjcko
slczm gvuig leohi akyxr qdbwd jcdjt qlvmd zjvhf wpqik glsvu lwsqd yusta
obttp zwgth ftfge ehavl cftnt kqxgv sdmks zorfb fpywt nqedw uqhpg yjvin
pfrms o
solxq psqnj egrlv nfzdm pqdli saido hlalr kuvmq nensv dmjbw tfghf vlrlk
kuqtq gukoj ekvoz xwsqp dfejh brjsc ptrkm nowdo gnkep ifzms qtxii boduq
ohgxw vfckh swqxb houbg ttmdz olpnb gwfvb dkdog lfvpw eordz akbvf xugrk
kevsi zfxln vcuhl hxngm kxwed ijiqp ltfdl zargs cdwky omqqp wmkts bzdrh
rfsfr azgrm ytvdx dtisx nywhk iavef bmtvk ityiw gjfga kaddp hxqcc xgnzg
wxqri dqsra wyxoq tmfxt ksyzy bddkm dbkxd vflaa ygmxt seidp tbrds tlqfa
hgalr sksrw ptogt thxed iteuh fjfne vfxdk nodlm ossmr znygr tnkpn goqli
wchhl aeoms rchkz mxphx pwgqk jevzq yxdqp zvkew ydkls mqssy pybtf arpgb
kcadx thujs vzxew rearw kldis qckqd mgfva zqhzb gkfyh lhtfy nybkp tzpwl
ftgoa mpmgl fpfmw hgxte jqfem jrwlh hxdfv ybmtx kacoz dmhsq ofxyl qakyh
qbewo drlns uzevn bvtfx pimyh akrwq vtxou krlhx hjzsr jdrbw thosc nwetu
dxude kbdol rtrxg kmzrm ayspz mchpt txilw ktzpx ohyhj tryxw hdzst vombs
oqpxy rdifh bjvha frkom fkgms azhsn hsdfy nqkvg zjmxt kuewr hhrsf wedqu
qtkrg svwtv kwlmd frorh pphqh gcmwf phmqs rsgff jvwbh tkorn tbmhg rinhy
qwpjr mfunb mubfp efbyb khlov nevaq fgsbd czkhv budjk woddp bbtkv bafda
lgqkz nxysq hsqxj uvjhy pqtct qfwyk hqlsv iwgdx djlot efzky ufkpy xavnc
ehbrk b
--
When I talk about running the bases, it't not baseball.
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: Storing RSA public/private keys
Date: Mon, 19 Jul 1999 21:24:27 +0200
[EMAIL PROTECTED] wrote:
>
> In a program I have created, I use RSA and Blowfish for
> encryption/decryption. When I store the private key on disk, this is
> how it is stored:
> The password to decrypt the private file is hashed with SHA. The hash
> and the private key is then GZiped together. The GZiped output is then
> encrypted with Blowfish using the users password. That output is saved
> to disk.
> To retrieve the private key, the user enters the password, the file is
> decrypted, and the hash is compared with the user's password hash. The
> only flaw I find is that if the decryption with an invalid password
> creates an output that the hash would equal the user's invalid password
> hash. This doesn't matter, because they will not have the private key.
Then what key do you use to encrypt the private key? I hope you are not
feeding the pass phrase string sec to blowfish!
The chance of getting the same hash would be one in 2^160, and that will
never happen.
If you use the hashed pass phrase as your blowfish key (which is wise),
the security of that would be 160 bits at most! And even an incorrect
pass phrase that results in the same key would decrypt your private key.
[BTW Nowadays 80 bit keys are about impossible to crack, so using
Moore's law it would take (160-80)*1.5 = at least 120 years for SHA-1 to
be obsolete. But Moore's law won't hold that long, there will be fysical
limits before that; read
http://x23.deja.com/[ST_rn=ps]/getdoc.xp?AN=397603286 for my (amateur)
view on key sizes].
> I am not worried at this point in development whether or not windows
> swaps the program to disk in the middle of this process, if the key is
> left in memory, etc. What I am wondering is this a secure way of
> storing a private key?
PGP 2.x just conventionally encrypts the decryption component 'd' and
some other secret stuff. That way you will give away no know plaintext
to the attacker and you will be able to deduce the public key from the
secret key in case you lose both your pass phrase and public key
certificate.
Happy programming,
Thomas
--
Buy an AMD K6-III <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: [EMAIL PROTECTED] (Dave Salovesh)
Subject: Re: another news article on Kryptos
Date: Mon, 19 Jul 1999 20:39:14 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) opined:
>I figure he knows of lots of possibilities for ciphers, more than most of
>us, but falls short of the numbers of them that are known to NSA. As far
>kinds of ciphers and associated possible keystructures, there are many
>more than any of us could ever describe, and heaven knows; I try to
>describe lots of them to prove that to a lesser degree.
I didn't check the online version, so it may be different, but the print
version has a bit in it that three (unnamed) NSA cryptographers have
also gotten to the same point, working on their own time. In the story,
here are no more details to that statement.
Call for speculation: If an NSA cryptographer was the first to solve
the last cipher, would the NSA allow an announcement of that fact?
I ask only because I can't decide which answer makes more sense. On one
hand, I think they might want the bragging rights for this exercise,
even if the details of who, how, and what remained secret as it has for
the current claim (yeah, I know that anyone could claim that if they
didn't need to support the claim, but I'm assuming that there's some
degree of honor involved).
On the other hand, I can imagine that they would want to keep their
precise level of skill somewhat obscured, and so would not want to make
even an oblique admission that this cipher is in their reach. Thus,
they'd never want to announce that they've solved the last cipher, even
once Jim manages to find and announce the solution.
Any thoughts?
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: why is it that nowadays people have to protect their conversations
Date: Mon, 19 Jul 1999 21:42:05 GMT
In article <[EMAIL PROTECTED]>,
"Markku J. Saarelainen" <[EMAIL PROTECTED]> wrote:
>
> ... why is it that nowadays people have to protect their conversations
> from CIA's eavesdropping .. .. of course, this is because of CIA's
> economic and business intelligence program that started late 1980's
> against its allies for the benefit of some specific industrial
> enterprises and corporations .... when they were talking about
changing
> their mission, this new mission has been followed for many years
already
> ... do not believe what you hear from the mass media, popular news
> sources or from some officials ... they are running the cover story in
> most cases .. there are currently many CIA intelligence operations
going
> on .. some are pretending to be promoting and developing specific
sales
> and marketing business / market intelligence software applications for
> specific companies for the benefit of some other enterprises
...sources
> and methods .....excellent ..... in addition, there are software
> companies that are actively involved in some specific CIA covert
actions
> and operations .... also there are total ghost businesses and
> development groups that are shadowing specific businesses for the
> benefit of certain industrial groups .... just focus on ownership
> structures ... investment bankers and some technology providers ...
>
>
But of course...
--
Democracy is the male majority legalizing rape.
UN Security Council = Democracy in Action - there is no appeal.
Welcome to the New World Order.
The US is not a democracy - US Constitution Article IV Section 4.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram)
Date: Mon, 19 Jul 1999 21:52:43 GMT
Roger Carbol <[EMAIL PROTECTED]> wrote, in part:
>John Savard <[EMAIL PROTECTED]> wrote:
>> So while it is true there is a way for the military to stay on-line
>> and maintain security, it is also true that that is not immediately
>> available.
>You seem to imply that being online necessarily includes being
>part of the Internet, which is of course false.
I'm only discussing the problems that might derive from being
connected to the Internet, thus I was using the term "on-line" in that
sense, rather than in the more general sense.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Mr. Kile A. Noy)
Subject: Re: another news article on Kryptos
Date: Mon, 19 Jul 1999 22:24:32 GMT
[EMAIL PROTECTED] (Dave Salovesh) wrote:
>Call for speculation: If an NSA cryptographer was the first to solve
>the last cipher, would the NSA allow an announcement of that fact?
I can't imagine any government agency passing up a chance to look good.
--
"Mr. Kile A. Noy" better known as [EMAIL PROTECTED]
01 2345 6 789 <- Use this key to decode my email address.
Fun & Free - http://www.5X5poker.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Length of public key in PGP?
Date: Mon, 19 Jul 1999 17:28:53 -0400
> P = 181 Q = 229 E = 7 D = 5863 PQ = 41449; If T = 33245, then
> ciphertext = 40140, decryptedtext = 33245. No problem.
> P = 137 Q = 191 E = 3 D = 17227 PQ = 26167; If T = 332453243,
> then ciphertext = 24661, decryptedtext = 1508. *** Problem ***
When you have a plain text that is too large for the key, you break it up
into blocks like so:
P = 137 Q = 191 E = 3 D = 17227 PQ = 26167:
T = 33245 C = ???? Decrypted = 33245
T = 3243 C = ???? Decrypted = 3243
(Sorry, don't feel like doing calculations.)
By breaking it up into blocks you fix the problem of T being bigger than PQ.
------------------------------
From: "Thijs vd Berg" <[EMAIL PROTECTED]>
Subject: Re: Benfords law for factoring primes?
Date: Mon, 19 Jul 1999 17:06:38 +0200
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
> > OK, but let's get the rules straight. Am I to _certify_ that the
> > number is prime before you factor it, or will you determine the
> > primality, ...
>
> My algorithm only works for prime numbers.
I have an algorithm which does a reverse decomposition given any number of
prime numbers!
------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram)
Date: Mon, 19 Jul 1999 21:43:27 GMT
On Mon, 19 Jul 1999 15:39:02 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
<SNIP Lengthy explanation>
I'm writing in response to both of your suggestions, (both you and the
person who responded to you.) Having quite a bit of networking and
system administration behind me, I suggest to you that what you
propose is overkill. It is also a phenomenal waste of money. Here's
why.
First off, when webservers are run on secure operating systems, they
are extremely safe from malicious users. (Note: MS Windows 95/98/NT
do NOT fall under the catergory of "secure Operating Systems") There
are only a few technical preventative measures necessary to ensure
that your system itself is unhackable. (Right now, hackers reading
this post are laughing, because they know as well as I do that nothing
is "unhackable." More on this later.) However, with simple firewalling
techniques and the use of a secure operating system, such as
GNU/Linux, setting up secure sites is very easy, and requires 0
special hardware. (We run a secure system/webserver/firewall on an AMD
K6-2 that runs like an i386.)
There are three simple configurations that can be made. Number one is
to have just the linux box, acting as both the firewall and the
webserver. This is not the better solution for a number of reasons.
The simplest to explain is that the use of the machine for multiple
purposes is a drain on resources. It slows everyone on the inside of
the firewall down, drastically. From a security standpoint, this is
horrible because if someone compromises your webserver, they also have
root access to your firewall. Uh-oh! With this solution, the webserver
contains only non-secure information, and all secure information is
contained within the firewalled area. The webserver makes any internal
requests to the network, and serves the data to its users.
The second modifies this idea a bit by placing _all_ of the web
content on the inside of the firewall, while still having the physical
webserver using the same machine as the firewall. The web files are
read as read-only by the webserver, and in order to alter content, you
must be on the inside of the firewall.
The third (safer) solution is to have the webserver inside of the
firewalls. Using IP Masquerading (or IP forwarding) you forward
requests for web documents to a server inside the firewall. The
webserver, now a seperate machine from the firewall, is completely
hidden on any other port than standard HTTP. As HTTP will be listened
to by a daemon process known as httpd, there is no risk of someone
altering content on your web-server. In this case, the only port
allowed _through_ the firewall (from the outside) is http port 80.
In the other two cases, there is no need for any other ports to
connect to the firewall from the outside, than port 80, and those used
for standard services such as incoming and outgoung mail. Telnet and
FTP are no-nos. If necessary, FTP is okay, so long as system admins
take appropriate measures for safeguarding their passwd file.
The reason I suggested above that no box is unhackable is because of
many systems' downfall, the users. A system is only as secure as its
weakest link, and 99% of the time, this is the users on the system.
[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
please remove -delete- for responses.
--
"I speak for me and not this company"
TO SPAMMERS:
Please view the definitions for
"telephone facsimile machine,"
"unsolicted advertisement," and the
prohibition and penalty for sending
unsolicited faxes before sending Un-
solicited Commercial E-mail to the
above address. Violators WILL BE
PROSECUTED. These can be found
in:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: NBE: Not crackable by brute force key search
Date: Mon, 19 Jul 1999 21:51:10 GMT
> Your a loon. ...
> I would encourage you to answer the questions in a
> professional manner...
You tell him!!!
--
Democracy is the male majority legalizing rape.
UN Security Council = Democracy in Action - there is no appeal.
Welcome to the New World Order.
The US is not a democracy - US Constitution Article IV Section 4.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: NBE: Not crackable by brute force key search
Date: Mon, 19 Jul 1999 21:53:56 GMT
> When it comes to 'reasonable discussions', you obviously can't talk.
In the
> past, you have used the following:...
My, my... Aren't we a forgiving group?
(I mean, why do you even bother responding - let the jerk go!)
--
Democracy is the male majority legalizing rape.
UN Security Council = Democracy in Action - there is no appeal.
Welcome to the New World Order.
The US is not a democracy - US Constitution Article IV Section 4.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 19 Jul 1999 16:28:56 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Compression and security (was: Re: How to crack monoalphabetic ciphers)
[EMAIL PROTECTED] wrote:
> Well in .LZH files (from LHA) I found that the average distance between
> the same byte value is not 256.0 (like it should) but +- 15 from that
> (in a 7MB file). In the output from a Lagged Fibo Sequence I got a
> distance of 256.0 +- 2. This indicates that the compressed stream is
> dependant on the input (which makes sense).
>
> However predicting the next output based on the previous (order-1) is
> not as easy. On average I found I got ~1/256 which is what is
> expected. Note this is huffman coding techniques. Basically you can't
> easily guess the next byte since it is already huffman coded.
No, you cannot reliably predict any byte! (Which makes sense, because
that would be equivalent to known-plaintext.) But you CAN look at a
=block= of bytes and, by examining its frequency distributions, say
"yes, this looks like the product of an LZH encoding," or "no, it does
not."
And it turns out that, when you apply an incorrect decryption-key to the
data, it immediately loses its "LZH-like" characteristics.
The correct encryption-key must be one of the ones that produces
favorable characteristics for all of the members of the archive
simultaneously (assuming, as is usually the case, that they are all
encrypted using the same key).
The general flaw exploited by the "known-plaintext attack" in this
cipher can be extended, albeit with mixed results, to take advantage of
this fact.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Length of public key in PGP?
Date: Mon, 19 Jul 1999 23:33:01 GMT
In article <[EMAIL PROTECTED]>,
> > Here is an example,
> >
> > P = 137 Q = 191 E = 3 D = 17227 PQ = 26167; If T = 332453243,
> >then ciphertext = 24661, decryptedtext = 1508. *** Problem ***
> >
> > Have I done something wrong?
>
> T must be < PQ.
>
> Essentially, RSA is a block cipher, where the block size is the size
> of the modulus. For longer messages, you must break up the message
> into blocks and encyrpt them separately. In practice, we generally
> make things simple by considering the block size to be slightly
> shorter than modules, by one bit or rounded down to the next byte
> boundary.
Thanks. This makes sense.
Does it help to break the ciphertext into pieces while decyphering, say,
it might save some time in calculation or something?
Weedlet
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Does base64 encoding lessen security?
Date: Mon, 19 Jul 1999 22:45:12 GMT
Michael Slass <[EMAIL PROTECTED]> wrote, in part:
>My question is about
>whether the base64 encoding renders a brute-force attack easier
The session key should be encrypted by RSA while still in pure binary
form. Base-64 encoding should only be applied to the binary encrypted
data as the very last step, so that if the data were sent as pure
binary instead, the attacker could base-64 encode it himself.
If indeed a system applied base-64 encoding, and then encrypted the
resulting ASCII characters as binary data, that would be a serious
error.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
