Cryptography-Digest Digest #485, Volume #12 Sat, 19 Aug 00 03:13:01 EDT
Contents:
Re: Bytes, octets, chars, and characters ("Bruce G. Stewart")
Re: blowfish problem ("Bruce G. Stewart")
Re: DES: Say it or spell it? (Newbie question) (Nicol So)
Re: How strong is this algorithm? ("Lyalc")
Re: Cryptography and Content Protection ("Lyalc")
Re: Intermittent stream cipher? (Benjamin Goldberg)
Re: Java Random Numbers (Benjamin Goldberg)
Re: OTP using BBS generator? (Mok-Kong Shen)
Re: OTP using BBS generator? (Mok-Kong Shen)
Re: Secure VoIP & IM (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Bruce G. Stewart" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Sat, 19 Aug 2000 04:22:23 GMT
David Hopwood wrote:
> > And to show that this is not just crazy C programmers talking, see
> > this (admittedly non-normative) quote from the Jargon File:
> >
> > byte /bi:t/ n.
> >
> > [techspeak] A unit of memory or data equal to the amount used to
> > represent one character;
>
> But, this definition is wrong, because C 'char' != character in general.
> It's very common for 1, 2, 4, or variable numbers of octets or bytes to
> be used to represent a character (both in C programs, the terminology
> used in the C specs notwithstanding, and in other contexts). The use of
> the word "character" to mean anything other than a unit of text (such as
> a symbol, letter, etc., or possibly a control code), should be strenuously
> resisted; characters are *not* units of storage.
Well, heck, it just says the amount to represent one character, not the
amount to represent any character, so variable-length mbcs codes could
get off the hook on a technicality.
------------------------------
From: "Bruce G. Stewart" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sat, 19 Aug 2000 04:27:35 GMT
Paul Schlyter wrote:
>
>
> There are no "hardware bytes" on word-addressed machines. The "byte" is
> there completely a software construction.
Device interfaces for printers and terminals might be "aware" of such
conventions though.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: Sat, 19 Aug 2000 00:27:20 -0400
Reply-To: see.signature
"Douglas A. Gwyn" wrote:
>
> ... (DES on the other hand is
> a pure acronym and thus by conventional English rules
> is pronounced as the sequence of individual letters.)
Talking about acronyms, there seems to be some disagreement as to what
counts as an acronym. Some people insist that an acronym must be
pronounceable, others think otherwise. One explanation of the
distinction that I've heard is that an acronym is supposed to be a
"real" word, not merely an abbreviation of the words from which it came.
As real words, acronyms are often pronounceable.
Based on *this* particular interpretation, words like "BASIC", "laser",
and "radar" are acronyms, but "DES", "NSA", & "FBI" are only
abbreviations, meaning that they are only shorthands for their full
expansions, but not independent words themselves. (It is interesting to
note that based on this understanding, "AT&T" used to be just an
abbreviation, but is now an acronym.)
I think based on conventional English rules, "DES" should be pronounced
as "D-E-S", because it is *not* an acronym.
--
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: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: How strong is this algorithm?
Date: Sat, 19 Aug 2000 15:08:53 +1000
Problem 1) who pays for the smartcards, and the necessary readers, and
hint, bond investments are unlikely to fund this expenditure
Reality 1) banking and payments systems already do this - it's called ATM
transactions, just credited to different recipients (a bank account instead
of a cash dispenser)
It's trivial to generate single use symmetric keys that automatically
synchronise in each message, regardless of reception order, and without
requiring new master keys, or PK overheads. Some schema for this can
provide forward and backward message security as well i.e. breaking a single
message does not lead to easier access to previous or subsequent messages.
The business model is not neceessarily dependent upon the technology model
or vice versa.
Jeff Davies wrote in message <[EMAIL PROTECTED]>...
>I have an idea for a non-profit electronic cash system (a bank)
>for which I have devised I think a new algorithm.
>Can anyone tell me how to evaluate how strong this is??
>
>Full details of business plan and crypto method below:
>Jeff Davies
>[EMAIL PROTECTED]
>
>
>ELECTROCASH PROPOSAL 0.02
>=========================
>Revisions:
>0.01 to 0.02:
>18.8.2000 SJD
> - Mission statement added,
> - progress to date added,
> - encryption notes modified.
> - RMS idea to use Government bonds to finance added.
>
>
>
>Mission:
>"To provide an electronic cash system that is instantaneous, based on
>totally free
>standards, very secure, and self financing".
>
>
>Progress to date:
>-----------------
>
>www.electrocash.org already purchased (by S.J. Davies).
>Yep, that's right, it's going to be a non-profit making organisation.
>In the UK, S.J. Davies is setting up a Registered Charity to be the
>legal
>corporate presence of Electrocash in the UK.
>
>1. Charity Commission, (+44) 0870-333-0123
>Phoned 18.8.2000 for forms.
>"Will be sent out today to SY24 5BZ".
>
>2. Companies House UK, Cardiff (+44) 029-2038-8588.
>Phoned 18.8.2000 for starter pack for company limited by guarantee.
>"Will be sent out today to SY24 5BZ" - SJ Davies postcode".
>Also, name is available.
>
>To Do:
>------
>1. Identify a means of distributing the keys. Perhaps this is floppy
>disks for
>older computers, Compact Flash or SMART cards or Memory Sticks for other
>devices.
>
>2. Identify people to be trustees of UK charity arm of electrocash -
>perhaps Richard
>Branson?
>
>3. Finish implementing a test system. Java Client is currently in
>progress.
>
>4. Look at survival rates for UDP packets across the internet.
>
>
>Description:
>============
>
>In the bank, there are never any charges.
>This is because income is derived totally from investment of a
>proportion of the
>credited funds in government bonds.
>There is no credit since all money is transferred instantly between
>accounts.
>
>There might be a BACS gateway (British Automated Clearing System) to the
>system to allow people to transfer
>to/from people who do not have accounts at Electrocash.
>
>This idea is public licence:
>
>Technology
>----------------
>All technology is non-proprietary, and any Electrocash technology is
>Public Licenced to:
>1. prevent another standard usurping Electrocash technology
>2. prevent another company patenting Electrocash technology and
>enforcing the patent by
> superior legal resources.
>
>Implementation
>---------------------
>1. All transactions are processed instantaneously (1 second max).
> You cannot spend money you haven't got.
> No bank letters, no charges.
>
>2. The servers
> .. run Linux or FreeBSD perhaps clustered, perhaps Beowulf cluster.
>Perhaps Bastille Linux.
> Core parts (IO) are very controlled and the code audited.
> All daemons like telnet, ftp, inetd super server are disabled.
>Routing disabled in
> kernel. Only the transaction port is active. (You can't even ping).
>Perhaps long
> term, the Ether driver is restricted to this port only as well.
> Customer Account balances are held in RAM. (100 million customer's
>balances as
> a fixed point 32 bit uint value would take 400 megabytes in a world
>where 2 gig
> of RAM is pretty commonplace on big servers).
> A single 100 megabit link could carry (based on 100% utilisation
>which might be achievable
> if there is only an incoming router and a single system on a segment
>- ie no collisions),
> 6000 transactions per second (based on single 1500 byte udp packet
>per transaction).
> If 10 million people make 200 transactions per day based around a
>core 10 hours of the day,
> this is two billion transactions per day, and represents three
>million megabytes of data
> per day (note the active part or each packet is very very small).
> The ten hour day is 360,000 seconds, and so, there are about 5500
>transactions per second.
> i.e. a single 100 megabit link can carry the transactions of 10
>million people.
> Obviously there are many factors which might lower this, but with
>parallel systems,
> and faster than 100 megabit (fibre etc), one can imagine that it will
>not be difficult
> to grow such simple technology.
>
>3. "Java Clients"
> The clients are Java based, open a socket and send an encrypted
>message consisting of
> SOURCE_ACCOUNT, DESTINATION_ACCOUNT, CASH_AMOUNT. Note heavy
>checksums ensure
> correct accounts are specified.
>
>4. The encryption technology is as follows:
>
> Note I have called this proposal "256 bit" however, I think it is
>stronger than traditional
> 256 bit methods. Instead of changing a pattern of bits larger than a
>character into an
> equivalent, random values scramble the message bits into a random
>packet 128 times larger.
>
> Electrocash will use Symmetric keys. Traditionally, asymmetric keys
>are used to prevent possibility of
> compromisation of the person's key from the server, where a third
>party could pretend to
> be the person. However, Clients are at the time of writing, far more
>vulnerable than
> the server. As a result, the private key is probably more likely to
>be lost than public key.
> So, as asymmetric are less strong per bit (2300 bit asymmetric is
>equivalent
> to about 256 bit symmetric in strength), multiple symmetric keys
>will be used with
> Electrocash.
> The key works as follows: for each bit in the packet (encrypted
>packet length is 256 bits)
> there is a 16 bit word specifying it's position in a larger word
>where unmapped bits have
> random values. At the outset, the upper two bits of the 16 bit word
>will not be used,
> as a single udp packet of around (max) 1500 bytes is standard on
>networks sent.
> Naturally, therefore, the encrypted bit position can be one of 4096
>(from it's original
> position within 256 bits).
> Each key has 256 off 16 bit words (totalling 512 bytes) positioning
>the encrypted bits
> within the larger packet. The values in the key are originally
>generated by Electrocash
> Server using a psuedo-random binary sequence generator (cannot
>repeat within 256 values).
> The unencrypted part of the packet gives a 16 bit integer choosing
>the key from
> the 2048 supplied every month in a 1 megabyte smartcard (or
>similar).
> Each key is used for only one transaction (this might be modified if
>it proves unworkable).
>
> Per user, 2048 keys are created per month, and distributed by
>snailmail on a smartcard or similar.
>
> There is no certification mechanism, as this can be bruteforced. you
>can't rely on client's being secure.
> The encryption algorithm is created outside the US, so that it is
>not subject to US export restrictions.
> As no data is stored in encrypted form, this should comply with UK
>"Rights of the People Bill".
> When Client talks to server, first unencrypted message specifies
>account number and encryption key to use
> from the 2048 sent. There is never a need for personal accounts for
>the same encryption key
> to be used twice. So when a key is used, it is discarded.
> This makes bruteforcing impossible. The client used might be
>compromised. In the case of a compromised client
> money lost is at the account holder's own risk.
>
> Ultimately, mobile phones are the target market, using JINI,
>Javasoft's embedded java product.
>
> As RMS suggested that the level of encryption might be a bit a bit
>excessive, if this
> is a new idea, I'd like to call it "Jeff's Hammer". If it isn't new,
>i'd like to use
> the name for the implementation.
>
>
>5. "Micropayments"
> for online services in future years will be effected through a
>download a buffer of ecash to
> a micropayments centre where the micropayments occur. Micropayments
>will not go directly to Electrocash.
>
>6. "Reviewing previous transactions":
> Interfaces with the same ip address as the system that holds the
>current account
> balances will be present on other machines connected to the same
>segment.
> (Note the router routing in new transactions is the only device to
>"talk" on the
> segment, all others listen).
> These other machines simply record each transaction against both
>accounts in a
> binary file for each account.
> (Note the transaction is about 256 bits unencrypted - 4 bytes.).
> This means if a million account holders had 20000 transactions on
>file, (say 2 years)
> then this would take 80 billion bytes or 80 gig of disk space.
>Currently in
> terms of ordinary PC IDE hard disks, this represents around £500
>(about $700 or 700 euros).
>
> Backups could be effected by mirror across a VPN across the world.
> Regular auditing and checksums ensure data integrity.
>
>Jeff Davies
>[EMAIL PROTECTED]
>
>
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Cryptography and Content Protection
Date: Sat, 19 Aug 2000 15:12:16 +1000
who is trusting what here?
What is the desired outcome, commercially, and technically?
If the shopkeeper is trusting the printer to say "transaction denied"
thereby getting the cusotmer to pay with another means (another card, or
cash perhaps), what stops a false printer being susbtituted, which prints
"transaction denied" every 5th (or ratio of your choice) transaction?
Lyal
Adriano Prado wrote in message <8njsc3$b7s$[EMAIL PROTECTED]>...
>Ok, let me be clearer...
>
>What is my 'system':
>
>Alice is a point-of-sale printer (the one used in supermarket).
>Bob is a computer.
>
>What I need:
>The printer respond to a set of defined commands.
>This commands are sent by the computer via a RS-232 serial port.
>
>There are some of these commands that are restrict, the computer has
>to send a key that is unique to each printer so it can be accepted.
>That is, the same computer communicates with more than one printer,
>but for each one it has to send a specific key.
>
>So, if one wants to use such set of commands, he has to call me,
>send the serial number of the machine, and then I compute the key.
>I pass the key by fax or e-mail. He then enter with the key in the
>communication program who will send (the key) to the printer.
>The printer should be able to see if the key is right for its serial
>number.
>
>capisce?
>
>
>thanx!!!!
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Intermittent stream cipher?
Date: Sat, 19 Aug 2000 06:23:09 GMT
mconroy wrote:
>
> I would like to know where I might find a cipher algorithm that allows
> me to stream plaintext input on an intermittent basis. The
> application is logging messages to a file which must be encrypted.
> The file has to remain encrypted at all times. However, opening the
> file, decrypting, adding ONE line, and reencrypting just doesn't make
> sense. I know there are a few commercial encrypted volume solutions,
> but I can't believe there isn't an algorithm out there built to do
> this sort of thing. Then again, I'm in Dilbert-hell and I've only had
> this assignment for a week. Using blowfish and twofish (with mcrypt
> under RH6.2) I can write one message and decrypt the file
> successfully. However, all subsequent messages decrypt with the first
> few bytes mangled. This happens regardless of the mode I choose.
> (which may, in fact, be a problem with mcrypt). If this isn't the
> forum for this type of question, please accept my apologies...and
> please point me in the right direction.
>
> Thanks,
> Mike Conroy
Use the stream cipher of your choice, and discard from it however many
bytes are already in the file. Then use it to encrypt the line you're
adding. To make this easier, you can use a block cipher in counter
mode, which makes skipping x*blocksize bytes as simple as starting the
counter at x instead of 0.
--
"There's a mathematical reason not to trust Christians... The Buddhists
believe that human lives repeat. The atheists believe that human lives
terminate. That means that the Christians must believe that humans are
irrational."
- Matt Katinas
"Not necessarily... they could think that humans are imaginary."
- Rob Pease, in response to the above
"Of course Christians think humans are irrational: They believe humans
are transcendental, and all transcendentals are irrational. I suppose
that all we can be certain of is that humans are complex."
- Me, in response the the above
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Java Random Numbers
Date: Sat, 19 Aug 2000 06:23:13 GMT
Scott Fluhrer wrote:
[snip]
> It looks like it has a few bugs. In particular, I believe that char's
> in Java are always 8 bits, and so anytime you try to store something
> in the "upper 8 bits", it gets lost.
I haven't looked at the code at all, but I do happen to know that in
java, a 'char' is an unsigned 16 bit value, suitable for any unicode
character. To get an 8 bit value in java, use a 'byte'.
--
"There's a mathematical reason not to trust Christians... The Buddhists
believe that human lives repeat. The atheists believe that human lives
terminate. That means that the Christians must believe that humans are
irrational."
- Matt Katinas
"Not necessarily... they could think that humans are imaginary."
- Rob Pease, in response to the above
"Of course Christians think humans are irrational: They believe humans
are transcendental, and all transcendentals are irrational. I suppose
that all we can be certain of is that humans are complex."
- Me, in response the the above
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Sat, 19 Aug 2000 08:53:49 +0200
"Trevor L. Jackson, III" wrote:
>
> Mok-Kong Shen wrote:
>
> > Tim Tyler wrote:
> > >
> > > Imagine a rare spy, who - after landing in enemy territory - opens up
> > > his OTP and prepares to report that his espionage mission began
> > > successfully. Scanning the pages, he finds all the symbols are zeros.
> > > Imagine his dismay ;-)
> >
> > Why? If the spy knows that his agency has given him a
> > true OTP and he also happens to be a crypto theoretician,
> > he will not hesitate a micro-second before applying the
> > pad!
>
> Is the message as secure if he does not calculate the ciphertext produced by
> the null pad and simply sends the plaintext?
In the time of science and technology, one always operates
with a fair amount of 'belief', just as in ancient times.
If one boards an airplane, is the flight secure? If you
beieve the techniques, including all stuffs under automatic
computer control, then yes. If you don't believe, then no.
A belief can be pretty wrong though, see the recent
catastrophe of a supersonic aircraft. So under the
assumptions I made, the spy, having FULL belief on the
impeacability of the theory, should do his routine
encryption processing with the pad and send the message.
Not doing the processing and sending the plaintext
is a plain violation of the instructions he got from
the agency. Whether the effect turns out to be the same
is not an issue. As I said, he should not have visual
contact with the pad, if processing is automatic. If he
nonetheless examines it, there is an strong indication
of a probability that he is not sure whether the pad is
indeed an ideal OTP. In that case, his belief is in
question and the assumptions are not fulfilled.
>
> > BTW, if the process is automatic, he (and his
> > colleagues who oversee the OTP generation at the agency)
> > shouldn't have visual contact with the pad at all.
>
> Does looking at the pad influence the security of the system? I.e., is there
> an observer effect?
>
> In addition to the obviousness of the all-zeros pad, there are a slew of pads
> that produce trivial transforms. What should the spy do if he notices that
> the pad only changes the upper/lower case of letters (and space to a
> punctuation mark). Can he decide that the tedium of encryption is unnecessary
> (he's got a manual system) and it's safe to send the original text?
>
> Does skipping the trivial encryption step count as "using" the keypad? If
> not, the spy can not use the same key over and over.
>
> This system may have interesting possibilities -- it just needs good
> marketing. Where is Szopa when we need him?
To put the assumptions explicit: (1) The agency CAN make an
ideal OTP. (2) His colleagues make no errors. (3) The apriori
probability of the opponent guessing the message is zero.
(4) He applies the pad correctly. (5) He is an ABSOLUTE
adherent of theoretical cryptology, is full confident
that he has mastered the theory.
If I were at his position, I would have decided otherwise,
for condition (5) is unfortunately not fulfilled. That's
why I pleaded (in the part you snipped) to conservatively
apply statistical tests to all bit sequences in serious
applications, whether these be from (quasi-) OTP, BBS,
any other so-called 'provably secure' PRNGs, or simply
a mundane PRNG.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Sat, 19 Aug 2000 09:01:00 +0200
Tim Tyler wrote:
>
> Besides, you can hardly rest an "absolute" proof on something unproven,
> such as the difficulty of factoring. Factoring is /believed/ to be hard -
> but there's no absolute proof. Indeed, the quantum computation
> cheerleaders would have us believe that factoring may soon prove to be
> much, much easier than people had previously thought.
Most instances of the so-called 'provable security' involve
assumptions. Hence the term could under circumstances be
misleading. That's why I suggested in another follow-up
to replace it with a (unfortunately long-winded) phrase.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Secure VoIP & IM
Date: Sat, 19 Aug 2000 09:16:07 +0200
Mike wrote:
>
> SecuriPhone addresses the issue of unsecured voice and instant messaging
> over the Internet.
>
> It employs Russian Federation National encryption standards, GOST 28147-89,
> Digital signature 34.10-94, 34.11-94. using 256 bit secret and 512 bit
> public keys, with optimum Sbox values. www.securiphone.com
Interesting. Just curious: Is that 'exportable' or
're-exportable' (from a country not identical to Russia)?
M. K. Shen
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
