Death of antivirus software imminent

2007-12-30 Thread Anne Lynn Wheeler

Storm, Nugache lead dangerous new botnet barrage,289142,sid14_gci1286808,00.html

from above:

The creators of these Trojans and bots not only have very strong 
software development and testing skills, but also clearly know how 
security vendors operate and how to outmaneuver defenses such as 
antivirus software, IDS and firewalls, experts say. They know that they 
simply need to alter their code and the messages carrying it in small 
ways in order to evade signature-based defenses. Dittrich and other 
researchers say that when they analyze the code these malware authors 
are putting out, what emerges is a picture of a group of skilled, 
professional software developers learning from their mistakes, improving 
their code on a weekly basis and making a lot of money in the process.

... snip ...

... and somewhat related

Virtualization still hot, death of antivirus software imminent, VC says

from above:

Another trend Maeder predicts for 2008 is, at long last, the death of 
antivirus software and other security products that allow employees to 
install and download any programs they'd like onto their PCs, and then 
attempt to weed out the malicious code. Instead, products that protect 
endpoints by only allowing IT-approved code to be installed will become 
the norm.

... snip ...

and post about dealing with compromised machines folklore indeed

mentioning sophistication in other ways:

Botnet-controlled Trojan robbing online bank customers

from above:

If the attacker succeeds in getting the Trojan malware onto the victim's
computer, he can piggyback on a session of online banking without even
having to use the victim's name and password. The infected computer
communicates back to the Trojan's command-and-controller exactly which
bank the victim has an account with. It then automatically feeds code
that tells the Trojan how to mimic actual online transactions with a
particular bank to do wire transfers or bill payments

... snip ...

there have been some number of online banking countermeasures for
specific kinds of system compromises  like keyloggers ... but they
apparently didn't bother to get promises from the crooks to only limit
the kinds of attacks to those exploits.

some related comments on such compromised machines 2007: year in review 2007: year in review

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: 2008: The year of hack the vote?

2007-12-30 Thread Bill Stewart

Dan wrote:
 Let's not do this or we'll have to talk about JF Kennedy
 who, at least, bought his votes with real money.

That's because Democrats had become more professional,
and the tradition of buying votes with whiskey
only works for the retail level, not wholesale.

Dan also wrote:

May I point out that if voting systems have a level
of flaw that says only an idiot would use them, then
how can you explain electronic commerce, FaceBook,
or gambling sites?  More people use just those three
than will *ever* vote.

The primary threats of electronic voting machines aren't
to the individual voter,
who can slightly increase the chances of getting
his/her vote counted accurately by insisting on paper ballots,
but to the aggregate vote count, which can be hacked
if the precinct has _any_ electronic machines.

The big problem in Ohio appears to have been Denial of Service -
not that there weren't lots of other problems,
but electronic voting systems have sufficient complexity that
an elections department can arrange to have enough
missing parts or supplies or passwords or powercords or whatever
in demographically appropriate precincts so that the
results get skewed even without Other Technical Means.
Some of the black inner-city precincts had two-hour lines
(on a rainy day), while white Republican-leaning precincts
had all the equipment they needed.

(Also, if you're saying only an idiot would use it
and ask how gambling sites exist, the answer is that
only idiots gamble...   As Ed Gerck pointed out,
risk in e-commerce can be managed and amortized into the price,
but that doesn't work for voting.)

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Question on export issues

2007-12-30 Thread dan

Alan writes:
 | What are the rules these days on crypto exports.  Is a review
 | still required?  If so, what gets rejected?

The following is a recent interaction with specialty
export counsel, though somewhat modified as I detoxed
it from base64 to ASCII plaintext and from infinite
line length to fixed line length.

When you file, you have immediate permission to export
to, essentially, the anglophone democracies and western
Europe.  If you have heard nothing in 30 days elapsed
time, you are then free to export generally but you will
never be permitted to export to the embargoed country
list (Cuba, Iran, Sudan, Syria, North Korea, and Libya).




A. BIS Checklist of Questions:

1. Does your product perform cryptography, or otherwise
contain any parts or components that are capable of performing
any of the following information security functions?
(Mark with an X all that apply)
a.  _  encryption
b.  _  decryption only (no encryption)
c.  _  key management / public key infrastructure (PKI)
d.  _  authentication (e.g., password protection, digital signatures)
e.  _  copy protection
f.  _  anti-virus protection
g.  _  other  (please explain) : ___
2. For items with encryption, decryption and/or key management
functions (1.a, 1.b, 1.c above):

a. What symmetric algorithms and key lengths (e.g., 56-bit
DES, 112 / 168-bit Triple-DES, 128 / 256-bit AES / Rijndael) are
implemented or supported?

b. What asymmetric algorithms and key lengths (e.g., 512-bit
RSA / Diffie-Hellman, 1024 / 2048-bit RSA / Diffie-Hellman) are
implemented or supported?

c. What encryption protocols (e.g., SSL, SSH, IPSEC or PKCS
standards) are implemented or supported?
d. What type of data is encrypted?

B. BIS Review Requirements for Form 748-P.  If any inquiry
is not applicable, please state N/A.
(a) State the name of the encryption item being submitted for review.
 i. Enter the name of the manufacturer of the software.
 ii. Provide a brief technical description of the basic purpose
 to be served by the encryption;
 iii. Provide a brief description of the type of encryption used
 in the software; e.g., 168-bit Triple DES for xyz purpose, and
 1024-bit RSA for abc purpose.
(b) You would also need to provide brochures or other
documentation as well as specifications related to the software,
relevant product descriptions, architecture specifications and,
if required by BIS, source code.  You must also indicate whether
there have been any prior reviews of the product, if such
reviews are applicable to the current submission.  In addition,
you must provide the following information in a cover letter
accompanying your review request:

 (1) Description of all the symmetric and asymmetric encryption
 algorithms and key lengths and how the algorithms are used.
 Specify which encryption modes are supported (e.g., cipher
 feedback mode or cipher block chaining mode).

 (2) State the key management algorithms, including modulus
 sizes, that are supported.

 (3) For products with proprietary algorithms, include a textual
 description and the source code of the algorithm.

 (4) Describe the pre-processing methods (e.g., data compression
 or data interleaving) that are applied to the plaintext data
 prior to encryption.

 (5) Describe the post-processing methods (e.g., packetization,
 encapsulation) that are applied to the cipher text data after

 (6) State the communication protocols (e.g., X.25, Telnet or
 TCP) and encryption protocols (e.g., SSL, IPSEC or PKCS
 standards) that are supported.

 (7) Describe the encryption-related Application Programming
 Interfaces (APIs) that are implemented and/or supported.
 Explain which interfaces are for internal (private) and/or
 external (public) use.
 (8) Describe the cryptographic functionality that is provided
 by third-party hardware or software encryption components (if
 any).  Identify the manufacturers of the hardware or software
 components, including specific part numbers and version
 information as needed to describe the product.  Describe whether
 the encryption software components (if any) are statically or
 dynamically linked.

 (9) For commodities or software using Java byte code, describe
 the techniques (including obfuscation, private access modifiers
 or final classes) that are used to protect against decompilation
 and misuse.

 (10) State how the product is written to preclude user
 modification of the encryption algorithms, key management and
 key space.

 (11) For products which incorporate an open cryptographic
 interface as defined in part 772 of the EAR, describe the Open
 Cryptographic Interface.
 (12) We must provide sufficient information for BIS to
 determine whether the software qualifies for mass market
 consideration.  The regulations offer examples 

Philips/NXP/Mifare CRYPTO1 mostly reverse-engineered

2007-12-30 Thread Ralf-Philipp Weinmann


MiFare’s CRYPTO1 stream cipher has captured my attention for a while.  
However, hardware reverse-engineering is not a field I actively engage  
in. So I was very happy when Karsten Nohl (University of Virginia),  
Starbug and Henryk Plötz gave a talk at the 24C3 [the 24th Congress of  
the Chaos Computer Club taking place in Berlin at this very moment]  
yesterday evening showing that they have reverse-engineered most parts  
of this cipher. CRYPTO1 uses a 48-bit LFSR-based filter generator to  
generate key stream.

The filter function - if I understood correctly - uses 20 taps (this  
was not mentioned in the talk, I asked Karsten privately about this)  
however the degree of the boolean function implementing the filter,  
thus it remains to be seen whether algebraic attacks can be applied.  
Even if no algebraic attacks are applied, a BSW sampling TMTO will  
break CRYPTO1 completely. This was pretty obvious before they gave  
their talk, but now vendors actually have to worry about this being  
out in the wild once the feedback and the filter function have been  

My colleague Erik took photos of the slides which I put up on Zooomr  
[0]. A video recording of the talk should be available shortly and  
will be linked here.

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Question on export issues

2007-12-30 Thread Richard Salz
In my personal experience, if you are developing a mass-market item with 
conventional crypto (e.g., SSL, S/MIME, etc ) then it is fairly routine to 
get a commodity export license which lets you sell globally.

Disclaimers abound, including that I'm not a lawyer and certainly don't 
speak for IBM.


STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]