<![CDATA[[SecurityRatty] tag: cbc]]> http://securityratty.com/tag/cbc Mon, 02 Apr 2007 02:46:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[Carleton University phishing attack sends its population 10,000 messages linking to faked college site]]> http://securityratty.com/article/bbfee6fb897d88858b63e46b0ca29900 http://securityratty.com/article/bbfee6fb897d88858b63e46b0ca29900 Thu, 24 Jul 2008 06:47:40 +0000 university carletong university email messages email addresses attack june article press release email accounts tens Carleton University phishing attack sends its population 10,000 messages linking to faked college site <![CDATA[Canadian farmer personal information on stolen CCGA laptop]]> http://securityratty.com/article/59ad7c04243f6352dc04e5847a1515dd http://securityratty.com/article/59ad7c04243f6352dc04e5847a1515dd Security Breach

Date Reported:
6/4/08

Organization:
Government of Canada

Contractor/Consultant/Branch:
Canadian Canola Growers Association (CCGA)

Victims:
Farmers

Number Affected:
~32,000

Types of Data:
"social insurance numbers, bank account numbers and other data"

Breach Description:
"OTTAWA, June 5 (UPI) -- Prairie farmers in Canada are upset the federal government waited two months to tell them a laptop computer containing their personal data was missing."

Reference URL:
Winnipeg Free Press
CBC News
United Press International

Report Credit:
Lindsay Wiebe, Winnipeg Free Press

Response:
From the online sources cited above:

About 32,000 Canadian farmers are on the alert after learning a laptop containing their financial information has been stolen.

The laptop was stolen when a programmer working for the Canadian Canola Growers Association took the machine off-site for routine maintenance.
[Evan] No offense to programmers, but in my experience the ways they use information can be some of the most dangerous threats to information security.  There is no reason for a programmer to EVER have access to confidential production information.  Programmers should only be permitted to work with scrubbed information in a test and/or development environment.

CCGA general manager Rick White described the theft as a classic "smash and grab."
[Evan] Also classic as in another organization that either does not know how or is unwilling to properly secure confidential information.

The laptop has the bank account numbers and social insurance numbers of farmers who applied for Agriculture Canada's advance payments program, which is administered by the CCGA on behalf of the federal government.

Although the theft happened March 30, Canadians weren't sent letters until last week informing them

The federal department has sent letters out to all farmers affected by the theft.

The letter said the laptop was stolen from an undisclosed, remote location in Manitoba.

"We treat this very seriously," White said. "This is an unfortunate incident, a very low-risk one."
[Evan] Mr. White is probably not well versed in risk analysis.  Or incident response for that matter.

the strict security measures being used on the laptop reduce the chances of information being misused, White said.
[Evan] Like what?

"There was a very strong password protection on it, [and] there was a biometric fingerprint reader on it," he said. "That would prohibit anyone other than the user or the person with the password to access the data on the laptop."
[Evan] These are "strict security measures"?  My emphatic answer is NO!  These "strict security measures" are easily bypassed.

but the data was not encrypted
[Evan] The missing piece of the puzzle.  Why go through all of the (self-proclaimed) "strict security measures" and not employ encryption.  What you get with full-disk encryption is pre-boot authentication and this defeats the boot to CD attack.

Agriculture Canada spokesman Sean Malone said there were security features on the laptop, but a sophisticated hacker could likely bypass them.
[Evan] No sophistication required.  A novice could figure it out with Google, a CD, and 15 minutes.

So far, there have been no reports of identity theft among the farmers, the report said.

Pitblado LLP privacy lawyer Brian Bowman said the CCGA and agriculture department deserve credit for notifying people of the breach -- a move not required by Manitoba law.
[Evan] Just because CCGA is not required by law, doesn't mean that they deserve any credit for notification.  The information belongs to the victims not CCGA, and as owners of the information don't you think they should be informed of an incident that has the potential affect them personally?

Victim Reaction:
"If they're devilish enough to steal a computer, maybe they're devilish enough to do something with the information,"

"What frustrates me is that they've treated this like it's no skin off their back,"

"They've known this since then and they're only getting the letters out now?"

"I don't want to find out a mortgage has been taken out on our farm."

Commentary:
It is bad enough for an organization to lose confidential information on a poorly protected laptop, but what makes this more troubling is the apparent fact that they still view the practice that led to the breach as a low risk.  Clueless and sad.

Past Breaches:
Government of Canada:
December, 2007 - Passport Canada web site suffers serious breach
November, 2007 - Service Canada stolen laptop affects more than 1,600

]]> Sun, 08 Jun 2008 15:32:52 +0000 information laptop financial information confidential information laptop affects computer strict security measures ccga laptop computer Canadian farmer personal information on stolen CCGA laptop <![CDATA[Clever Museum Theft]]> http://securityratty.com/article/6a56823b5152f1872fe26e870cf20b38 http://securityratty.com/article/6a56823b5152f1872fe26e870cf20b38 Some expensive and impressive stuff was stolen from the University of British Columbia's Museum of Anthropology:

A dozen pieces of gold jewelry designed by prominent Canadian artist Bill Reid were stolen from the museum sometime on May 23, along with three pieces of gold-plated Mexican jewelry. The pieces that were taken are estimated to be worth close to $2 million.

Of course, it's not the museum's fault:

But museum director Anthony Shelton said that elaborate computer program printouts have determined that the museum's security system did not fail during the heist and that the construction of the building's layout did not compromise security.

Um, isn't having stuff get stolen the very definition of security failing? And does anyone have any idea how "elaborate computer program printouts" can determine that security didn't fail? What in the world is this guy talking about?

A few days later, we learned that security did indeed fail:

Four hours before the break-in on May 23, two or three key surveillance cameras at the Museum of Anthropology mysteriously went off-line.

Around the same time, a caller claiming to be from the alarm company phoned campus security, telling them there was a problem with the system and to ignore any alarms that might go off.

Campus security fell for the ruse and ignored an automated computer alert sent to them, police sources told CBC News.

Meanwhile surveillance cameras that were still operating captured poor pictures of what was going on inside the museum because of a policy to turn the lights off at night.

Then, as the lone guard working overnight in the museum that night left for a smoke break, the thief or thieves broke in, wearing gas masks and spraying bear spray to slow down anyone who might stumble across them.

It's a particular kind of security failure, but it's definitely a failure.

]]> Fri, 06 Jun 2008 01:04:38 +0000 compromise security security museum campus security security failure security system computer program printouts system key surveillance cameras Clever Museum Theft <![CDATA[Academy Learning Centres stolen computers affect seniors]]> http://securityratty.com/article/89621d79e70c35f86c3ad4252fd551ad http://securityratty.com/article/89621d79e70c35f86c3ad4252fd551ad Security Breach

Date Reported:
5/22/08

Organization:
Academy Hearing Centres

Contractor/Consultant/Branch:
None

Victims:
Patients (mostly seniors)

Number Affected:
"Dozens"

Types of Data:
Names, addresses, credit-card numbers, health information and health-card numbers

Breach Description:
"Dozens of Calgary seniors are alarmed after learning their credit-card numbers, addresses and health-card numbers were stored on computers that were stolen recently. The Academy Hearing Centre in Brentwood Mall, which provides hearing tests and equipment, mostly to seniors, recently mailed out letters warning of the theft."

Reference URL:
CBC News

Report Credit:
CBC News

Response:
From the online source cited above:

Dozens of Calgary seniors are alarmed after learning their credit-card numbers, addresses and health-card numbers were stored on computers that were stolen recently.

The Academy Hearing Centre in Brentwood Mall, which provides hearing tests and equipment, mostly to seniors, recently mailed out letters warning of the theft.

The Academy Hearing Centre refused the CBC's request for an interview, saying only that there is no need for clients to be alarmed.
[Evan] This is it?  Is this indicative of the service that one could expect from Academy Hearing Centres?  Organizations should be more open and willing to talk about what they do to protect confidential information, unless they don't know themselves.  Shame shame.

Victim Reaction(s):
"I got scared," said one elderly female client who purchased a hearing aid from the company.

She requested that her name not be released because she is worried about her security.

The woman said the thieves nabbed her name, address, health information and Alberta health-care number.

"It's the same thing, like somebody steals your social insurance number," she said.

She added that she was unable to change her health-card number.

"I called up Edmonton, the health insurance centre, and she said you have to wait about six months. Just have to notify your doctor, the family doctor. So somebody might be using my number, so let's hope it won't happen."

Commentary:
I wish I had more information to share about this breach, but this is all that is publicly available.  In anyone has anything more to share, please feel free to comment.  Posted on the Academy Learning Centres web site:

"if there is any question left unanswered, please do not hesitate to contact one of our team directly by calling: ph: 403. 210. 2482."

If you suspect that you may be affected by this breach, or if you want more information, I suggest that you call.  Victims can demand answers; after all they are the data owners.  What makes this breach especially difficult is the fact that it affects customers that are generally easy victims of fraud and deception.

Past Breaches:
Unknown

]]> Thu, 29 May 2008 05:14:25 +0000 seniors academy centres protect confidential information information breach description breach calgary seniors health information Academy Learning Centres stolen computers affect seniors <![CDATA[Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more]]> http://securityratty.com/article/d47e0757b7a447223299541c460a193c http://securityratty.com/article/d47e0757b7a447223299541c460a193c

Synopsis:  Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more

Welcome to Blue Box: The VoIP Security Podcast #78, a 40-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 17MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was originally recorded on February 25, 2008. Yes, that was two months ago... we know!

You may also listen to this podcast right now:

Show Content:

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

]]> Tue, 29 Apr 2008 10:56:49 +0000 voip security news news listener comment line comments listener comments comment line cisco phone podcast Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more <![CDATA[Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more]]> http://securityratty.com/article/5012fddf567c518c66082afa468b2250 http://securityratty.com/article/5012fddf567c518c66082afa468b2250

Synopsis:  Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more

Welcome to Blue Box: The VoIP Security Podcast #78, a 40-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 17MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was originally recorded on February 25, 2008. Yes, that was two months ago... we know!

You may also listen to this podcast right now:

Show Content:

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

]]> Tue, 29 Apr 2008 09:56:50 +0000 voip security news news listener comment line comments listener comments comment line cisco phone podcast Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more <![CDATA[Got Entropy ?]]> http://securityratty.com/article/e241bfde32ce971a3341a22fcb76c27d http://securityratty.com/article/e241bfde32ce971a3341a22fcb76c27d So I have been planning a series of podcasts on Cryptographic Controls. In the process of this planning, I fell into one of the classic traps that crypto-geeks fall into: obsessing about random number generators (RNGs).

(FYI, for the impatient, click here.)

There are two ways to generate random numbers on computers: (1) use a software program called a Pseudorandom Number Generator (PRNG) or (2) use a hardware random number generator. A Pseudorandom Number Generator uses a seed value to generate a sequence of numbers that appear random. The problem is that the same seed generates the same random sequence. The hardware based RNG observes and samples some physical phenomenon which is random, such as cosmic rays, RF noise, etc. (aka Entropy).

RNGs are important in Information Security because they are used to generate encryption keys, salts, etc. Historically, attacking RNGs has proven effective, such as the defeat of Netscape’s HTTPS sessions.

Most operating systems utilize a hybrid approach, implementing a PseudoRandom Number Generator that has a seed that is regularly updated through the collection of random hardware events. This process is called Entropy Collection or Entropy Harvesting. For most applications, this approach should be completely sufficient. However, one of the key assumptions is that the operating system has been up and running long enough for the seed value itself to become hard to predict through the collection of Entropy. Also, many of the Entropy collecting events come from properties of hardware devices, such as the minor variations in hard drive rate of rotation. As such, there are a few circumstances where the OS RNG may not be good enough for strong cryptographic key generation:

  • Live Boot CD ( The start state of the RNG may be predictable. )
  • Virtualized Hosts ( OS may be dependent on simulated events for randomness. )

( Given the exploding popularity of virtualization, this is an area worthy of research. Stay tuned. )

Design of the Got Entropy Service

Many RNGs (such as the one included in Linux, as well as OpenSSL’s) allow the addition of entropy from outside sources. So I started looking to Entropy sources I could use to bolster the RNGs on my virtual hosts (and other uses…). While I was looking into this, it occurred to me that I had an unused TV tuner card, a PVR-350.

When a TV is tuned to a channel with no local station, the ’snow’ on the screen is RF noise (the same as the static between stations on AM radios). But, for reasons beyond our scope, you never use a direct physical observation as the RNG. You have to ‘de-skew and whiten’ the data prior to sampling it. Here is the process that I use:

  1. Collect about 3 minutes of video ( about 130 MB data ).
  2. Using a random key and IV, encrypt the data ( using openssl & AES-128-CBC ).
  3. Discard the first 32k of the file.
  4. Use each of the following 32k blocks as samples.
  5. Compress each sample with SHA-256.
  6. Discard the last block.
  • Steps 2 and 3 remove any patterns, such as MPEG file formatting, from the data.
  • Steps 4 and 5 generate a 32-byte random value ( 1024 to 1 compression in the hash ).

Check it out at http://gotentropy.artofinfosec.com

Can an Attacker Broadcast a Signal to Undermine This?

Such an attacker could not remove RF noise from the received signal. Our eyes and brains are good at filtering out the noise in the TV video, but there is a lot of it. Part of the noise comes from the atmospheric background RF, but there are also flaws (noise) in the tuner’s radio and analog-to-digital capture circuitry.

I think this is a pretty strong RNG, and I have provided an interface for pulling just the values.

Also, I have written a script ( getEntropy.sh ) that will pull Entropy from the service and seed it into /dev/random on Linux.

Results from ENT

Here are results, from a sample run of the Got Entropy, analyzed by ENT ( A Pseudorandom Number Sequence Test Program provided by John Walker of www.fourmilab.ch - Thanks, John! ).

  • Entropy = 7.999987 bits per byte
  • Optimum compression would reduce the size of this 13366112 byte file by 0 percent.
  • Chi square distribution for 13366112 samples is 233.85, and randomly would exceed this value 82.48 percent of the time.
  • Arithmetic mean value of data bytes is 127.4767 (127.5 = random).
  • Monte Carlo value for Pi is 3.143054786 (error = 0.05 percent).
  • Serial correlation coefficient is -0.000078 (totally uncorrelated = 0.0).

Resources for the Curious…

Cheers, Erik

Art of Information Security would love your feedback !

Got Entropy ?

]]> Tue, 01 Apr 2008 22:55:47 +0000 entropy random 32-byte random byte hardware random entropy sources sequence random sequence pull entropy Got Entropy ? <![CDATA[Four stolen laptops at the Eastern School District]]> http://securityratty.com/article/e1598ac8c7e2c26266aaf0ed0209fba7 http://securityratty.com/article/e1598ac8c7e2c26266aaf0ed0209fba7 Security Breach

Date Reported:
2/21/08

Organization:
Eastern School District (St. John's, Newfoundland, CA)

Contractor/Consultant/Branch:
None

Victims:
Students

Number Affected:
~28,000

Types of Data:
Names, Medical Care Plan (MCP) numbers, addresses, grade levels, phone numbers, and names of parents/guardians.

Breach Description:
Four laptop computers were stolen from the Eastern School District Atlantic Place offices during a break-in that was discovered on February 17th, 2008.  One of the stolen laptops contained personal information belonging to students bussing to and from schools in the district.

Reference URL:
Eastern School District Media Release
CBC News online story

Report Credit:
Mary Tucker, Eastern School District

Response:
From the online sources cited above:

On Sunday, February 17, 2008 it was discovered that four laptop computers were stolen from the Eastern School District’s Atlantic Place offices.

The Royal Newfoundland Constabulary was contacted immediately and they are currently investigating this incident as a Break, Entry and Theft.

As part of the District’s internal investigation, it was discovered that one of the stolen computers contains an electronic database of bussing information regarding approximately 28,000 students.

This information includes student names, MCP numbers, addresses, grade levels, phone numbers and names of parents/guardians.
[Evan] Is all of this information needed in order to track kids on busses?  I suppose most of it is in case of emergency.  Not a good idea to store it on an unencrypted laptop though, eh?

The stolen computers are password protected, thus limiting access to information. Additionally, the Eastern School District has been advised by the MCP Commission that access to individual medical records is not at risk.
[Evan] Don't be fooled into thinking that the password is going to stop anyone except complete novices or the unmotivated.

"We are very concerned about this theft and possible breach of private information," says Darrin Pike, CEO/Director of Education, Eastern School District. "We have notified all authorities and school administrators and have also taken immediate action with our landlord at Atlantic Place to strengthen our physical security measures."
[Evan] AND encrypt confidential information, AND prohibit the storage of confidential information on mobile devices whenever possible, AND evaluate our internal information security controls, AND…

"We are very concerned," chief executive officer Darrin Pike. "Obviously it's not a good thing, it's not something we want to minimize."

"From what the RNC tells us, [thieves] tend to reformat the hard drives and resell them," Pike said in an interview.

"They're not interested in the data in most cases. They're just interested in the box."
[Evan] I think that this logic is becoming more and more dangerous.

The District will now begin the process of notifying parents which primarily affects 56 schools in the Avalon East region and one school in the Avalon West region.

Commentary:
A stolen laptop containing personal information is nothing really new.  What is new is the fact that this information belonged to children.

Keep sensitive data off laptops and other mobile devices.  IF it must be written to and/or stored on mobile devices, institute additional controls to protect the data against the physical theft of the device!  The fact that the district is going to "strengthen our physical security measures" is good, but it is far from addressing the root of the problem.

Past Breaches:
Unknown

]]> Thu, 21 Feb 2008 13:37:38 +0000 district eastern school district school information personal information confidential information encrypt confidential information computers laptop computers Four stolen laptops at the Eastern School District <![CDATA[Changing the SSL cipher order in Internet Explorer 7 on Windows Vista]]> http://securityratty.com/article/8dcae041db8c41664d643027b8c6437d http://securityratty.com/article/8dcae041db8c41664d643027b8c6437d Recently, the question of using AES for SSL has come up in the newsgroups and at some conferences. When IE makes an HTTPS connection to a web server, it offers a list of cipher supported cipher suites. The server then selects the first one from the list that it can match. The default order that IE follows is this:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL_CK_RC4_128_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA

When you study the list, you'll see that IE presents the algorithms in decreasing order of strength, but places the shorter bit-lengths first. Why? If longer bit lengths are more secure, shouldn't they be listed first?

Remember, encryption is the thing that buys you time against Immutable Law #3. But performing encryption itself takes time. So when choosing an algorithm and a bit length, one important consideration is to ask yourself this question: "How long do I need for my secrets to remain secret?"

We configure IE to use shorter bit lengths -- but never shorter than 128 bits, except for the last two that use no encryption -- because it gives you better performance than the longer bit lengths. In almost all cases, a 128-bit key is more than sufficient to protect the information you're exchanging over HTTPS.

However, if you require something longer, and want to change the default, you can. Here's how.

  1. Open your group policy editor by entering gpedit.msc at a command prompt.
  2. Choose Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
  3. There's only one item here: SSL Cipher Suite Order. Open it.
  4. Select Enabled.
  5. Now here's where you need to tread carefully. You'll see that the list is the same as above, but rather than formatted nicely with carriage returns, they're simply separated with commas. The first item in the list is:
          TLS_RSA_WITH_AES_128_CBC_SHA
    And the second item is:
          TLS_RSA_WITH_AES_256_CBC_SHA
    Cursor your way through the list. Change that first 128 to 256. Then cursor forward a bit more and change the 256 to 128.
  6. Feel free to change other orders, too, but keep your changes within algorithm types.
  7. OK your way out, close the group policy editor, and reboot.

Most of you probably won't need to do this -- I haven't. But for those who have regulatory requirements for using 256-bit AES, follow these steps and you'll be compliant.

]]> Wed, 07 Nov 2007 02:37:47 +0000 sha null sha cbc sha p384 cbc sha cbc sha p521 shorter bit lengths bit lengths cbc sha p256 256-bit aes Changing the SSL cipher order in Internet Explorer 7 on Windows Vista <![CDATA[Encryption Presentation - .NET Developers Group - NYC Microsoft Offices - June 21st]]> http://securityratty.com/article/94656caed39af9829462fd075056cb72 http://securityratty.com/article/94656caed39af9829462fd075056cb72 For those of you in NYC or the surrounding area, I will be doing a presentation on encryption at the .NET Developers Group on Thursday, June 21, 2007.  It’s a similar presentation to the one I’ve done for a number of user groups in the Southeast.  I made this presentation as a response to the flood of online code snippets for encrypting data.  While they are all fairly easy to use, they don’t explain what they do and often developers think their data is more secure than it actually is.

 

During the presentation, we’ll quickly cover some high level encryption basics (asymmetric, symmetric, and one way hashes), but will spend most of our time dealing with symmetric encryption; namely how and why you configure a symmetric algorithm to encrypt the data (ECB vs. CBC).  By the end of the session, you’ll finally understand what an initialization vector (IV) is used for and the proper way to create and store it.

 

Don’t worry if you don’t understand what half of that meant.  I’ll be sure to explain everything as we go along. 

 

You can also find a fair amount of the content from the presentation here in an article I wrote a while back. 

 

]]> Mon, 02 Apr 2007 02:46:00 +0000 encryption presentation level encryption basics similar presentation net developers developers symmetric symmetric algorithm symmetric encryption Encryption Presentation - .NET Developers Group - NYC Microsoft Offices - June 21st