asymmetric encryption

Is there a step by step cookbook on setting up asymmetric encryption. My
goal is to encrypt a couple of tables from one of my dataabses. Thanks!Do not use asymmetric key encryption to protect data; it is too slow for
that purpose, plus there are limitations on how large a piece of data you
can encrypt. For symmetric key encryption examples, see my blog:
http://blogs.msdn.com/lcris/ .
Thanks
Laurentiu Cristofor [MSFT]
Software Design Engineer
SQL Server Engine
http://blogs.msdn.com/lcris/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Keith" <Keith @.discussions.microsoft.com> wrote in message
news:511B39A3-071D-45D7-8C7B-C33C5E744385@.microsoft.com...
> Is there a step by step cookbook on setting up asymmetric encryption. My
> goal is to encrypt a couple of tables from one of my dataabses. Thanks!|||It's an awesome encryption blog. If anyone needs to learn
more on encryption in 2005, it's *the* resource. Just
checked your blog today - thanks for the posting the
proposed updated sp_helprevlogin. Awesome!
Thanks for all time you've put into your blog.
-Sue
SQL Server MVP
On Wed, 5 Apr 2006 10:50:02 -0700, "Laurentiu Cristofor
[MSFT]" <laur@.nospam.com> wrote:

>Do not use asymmetric key encryption to protect data; it is too slow for
>that purpose, plus there are limitations on how large a piece of data you
>can encrypt. For symmetric key encryption examples, see my blog:
>http://blogs.msdn.com/lcris/ .
>Thanks|||Awesome... Thanks for the help. Will this method encrypt data already in m
y
database?
"Laurentiu Cristofor [MSFT]" wrote:

> Do not use asymmetric key encryption to protect data; it is too slow for
> that purpose, plus there are limitations on how large a piece of data you
> can encrypt. For symmetric key encryption examples, see my blog:
> http://blogs.msdn.com/lcris/ .
> Thanks
> --
> Laurentiu Cristofor [MSFT]
> Software Design Engineer
> SQL Server Engine
> http://blogs.msdn.com/lcris/
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> "Keith" <Keith @.discussions.microsoft.com> wrote in message
> news:511B39A3-071D-45D7-8C7B-C33C5E744385@.microsoft.com...
>
>|||Yes, you can encrypt existing data. Here are some caveats: The output of
encryption is varbinary, so if you're trying to encrypt a table column that
is not varbinary, you'll need to change the table definition. The ciphertext
is also larger than the cleartext, so you may need to do this even if your
data is already varbinary; if the column is too small.
One other caveat is that we only allow encrypting values less than 8k.
See this blog entry for additional details:
http://blogs.msdn.com/yukondoit/arc.../24/496521.aspx
Note that the YukonDoIt blog is not active anymore. Raul, who wrote this
post, now has a blog at:
http://blogs.msdn.com/raulga/
Thanks
Laurentiu Cristofor [MSFT]
Software Design Engineer
SQL Server Engine
http://blogs.msdn.com/lcris/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Keith" <Keith@.discussions.microsoft.com> wrote in message
news:2654724A-2B10-4F94-B51E-C1A2B2FD7A30@.microsoft.com...[vbcol=seagreen]
> Awesome... Thanks for the help. Will this method encrypt data already in
> my
> database?
> "Laurentiu Cristofor [MSFT]" wrote:
>|||Thank you. I'm glad you found my blog posts useful.
Laurentiu Cristofor [MSFT]
Software Design Engineer
SQL Server Engine
http://blogs.msdn.com/lcris/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:q0o832t10pvevq2a0v0pl3der2q3vmfau6@.
4ax.com...
> It's an awesome encryption blog. If anyone needs to learn
> more on encryption in 2005, it's *the* resource. Just
> checked your blog today - thanks for the posting the
> proposed updated sp_helprevlogin. Awesome!
> Thanks for all time you've put into your blog.
> -Sue
> SQL Server MVP
> On Wed, 5 Apr 2006 10:50:02 -0700, "Laurentiu Cristofor
> [MSFT]" <laur@.nospam.com> wrote:
>
>|||If you use symmetric encryption do the end users, connecting with a
front-end, need to input a password to acess the encrypted data? Or will
their logging into the system grant them access to the encrypted data?
"Laurentiu Cristofor [MSFT]" wrote:

> Yes, you can encrypt existing data. Here are some caveats: The output of
> encryption is varbinary, so if you're trying to encrypt a table column tha
t
> is not varbinary, you'll need to change the table definition. The cipherte
xt
> is also larger than the cleartext, so you may need to do this even if your
> data is already varbinary; if the column is too small.
> One other caveat is that we only allow encrypting values less than 8k.
> See this blog entry for additional details:
> http://blogs.msdn.com/yukondoit/arc.../24/496521.aspx
> Note that the YukonDoIt blog is not active anymore. Raul, who wrote this
> post, now has a blog at:
> http://blogs.msdn.com/raulga/
> Thanks
> --
> Laurentiu Cristofor [MSFT]
> Software Design Engineer
> SQL Server Engine
> http://blogs.msdn.com/lcris/
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> "Keith" <Keith@.discussions.microsoft.com> wrote in message
> news:2654724A-2B10-4F94-B51E-C1A2B2FD7A30@.microsoft.com...
>
>|||It depends on how you design your database application. Both of these
scenarios are possible.
Laurentiu Cristofor [MSFT]
Software Design Engineer
SQL Server Engine
http://blogs.msdn.com/lcris/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Keith" <Keith@.discussions.microsoft.com> wrote in message
news:D8AE6555-A2C3-499D-838D-546F8D13092A@.microsoft.com...[vbcol=seagreen]
> If you use symmetric encryption do the end users, connecting with a
> front-end, need to input a password to acess the encrypted data? Or will
> their logging into the system grant them access to the encrypted data?
> "Laurentiu Cristofor [MSFT]" wrote:
>

Asymmetric data syncronization: possible?

I have two sql server instances on two different machines with the same db;
on the first machine some tables need to be copied on the second machine,
and on the second machine some other tables need to be copied on the first;
all the tables are related with the others in some way.
It is possible to make that replication?
Thanks
Mik
I'm wondering if the same data can be changed on each node? If so, then it
sounds like you need either merge or updating transactional subscribers
(queued or immediate). I'd control this from one server designated as the
publisher and synchronize this way. If this is not the case, then both nodes
could be set up as transactional publishers.
Rgds,
Paul Ibison

Asymmetric communication from ms-sql-m protocol from an SQL Cluster

We are installing an application that requires access to the ms-sql-m
protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
we are using is part of an N+1 cluster. The issue is that when we try
to communicate to the node instance xxx.xxx.123.226 recieve the
ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
an asymmetric IP communication and the response appears to be dropped
by the request as one might expect. This causing our installation to
fail.
Has anyone run into this issue before, no of a common misconfiguration
in clustering services that leads to this, or aware of any documented
bug?
Thanks in advance for you posts.
Actually, this is typical of MS cluster applications. The response comes
back from the underlying NIC address, not the cluster virtual address. It
ain't a bug, it's a feature. Or at least it has always operated this way
and could therefore be considered a standard.
Sorry this isn't the answer you were looking for, but it is the way the
system actually works.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<ddnash@.gmail.com> wrote in message
news:1165524543.657106.172130@.79g2000cws.googlegro ups.com...
> We are installing an application that requires access to the ms-sql-m
> protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
> we are using is part of an N+1 cluster. The issue is that when we try
> to communicate to the node instance xxx.xxx.123.226 recieve the
> ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
> an asymmetric IP communication and the response appears to be dropped
> by the request as one might expect. This causing our installation to
> fail.
> Has anyone run into this issue before, no of a common misconfiguration
> in clustering services that leads to this, or aware of any documented
> bug?
>
> Thanks in advance for you posts.
>
|||I found the following article that does acknowledge the issue and
states that MS has chosen not to address it at this point, but there
are a couple of workarounds.
http://blogs.msdn.com/sql_protocols/archive/2006/02/27/539706.aspx
Thanks for the post.
Geoff N. Hiten wrote:[vbcol=seagreen]
> Actually, this is typical of MS cluster applications. The response comes
> back from the underlying NIC address, not the cluster virtual address. It
> ain't a bug, it's a feature. Or at least it has always operated this way
> and could therefore be considered a standard.
> Sorry this isn't the answer you were looking for, but it is the way the
> system actually works.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> <ddnash@.gmail.com> wrote in message
> news:1165524543.657106.172130@.79g2000cws.googlegro ups.com...
sql

Asymmetric communication from ms-sql-m protocol from an SQL Cluster

We are installing an application that requires access to the ms-sql-m
protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
we are using is part of an N+1 cluster. The issue is that when we try
to communicate to the node instance xxx.xxx.123.226 recieve the
ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
an asymmetric IP communication and the response appears to be dropped
by the request as one might expect. This causing our installation to
fail.
Has anyone run into this issue before, no of a common misconfiguration
in clustering services that leads to this, or aware of any documented
bug?
Thanks in advance for you posts.Actually, this is typical of MS cluster applications. The response comes
back from the underlying NIC address, not the cluster virtual address. It
ain't a bug, it's a feature. :) Or at least it has always operated this way
and could therefore be considered a standard.
Sorry this isn't the answer you were looking for, but it is the way the
system actually works.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<ddnash@.gmail.com> wrote in message
news:1165524543.657106.172130@.79g2000cws.googlegroups.com...
> We are installing an application that requires access to the ms-sql-m
> protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
> we are using is part of an N+1 cluster. The issue is that when we try
> to communicate to the node instance xxx.xxx.123.226 recieve the
> ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
> an asymmetric IP communication and the response appears to be dropped
> by the request as one might expect. This causing our installation to
> fail.
> Has anyone run into this issue before, no of a common misconfiguration
> in clustering services that leads to this, or aware of any documented
> bug?
>
> Thanks in advance for you posts.
>|||I found the following article that does acknowledge the issue and
states that MS has chosen not to address it at this point, but there
are a couple of workarounds.
http://blogs.msdn.com/sql_protocols/archive/2006/02/27/539706.aspx
Thanks for the post.
Geoff N. Hiten wrote:
> Actually, this is typical of MS cluster applications. The response comes
> back from the underlying NIC address, not the cluster virtual address. It
> ain't a bug, it's a feature. :) Or at least it has always operated this way
> and could therefore be considered a standard.
> Sorry this isn't the answer you were looking for, but it is the way the
> system actually works.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> <ddnash@.gmail.com> wrote in message
> news:1165524543.657106.172130@.79g2000cws.googlegroups.com...
> > We are installing an application that requires access to the ms-sql-m
> > protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
> >
> > we are using is part of an N+1 cluster. The issue is that when we try
> > to communicate to the node instance xxx.xxx.123.226 recieve the
> > ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
> > an asymmetric IP communication and the response appears to be dropped
> > by the request as one might expect. This causing our installation to
> > fail.
> >
> > Has anyone run into this issue before, no of a common misconfiguration
> > in clustering services that leads to this, or aware of any documented
> > bug?
> >
> >
> > Thanks in advance for you posts.
> >

Asymmetric communication from ms-sql-m protocol from an SQL Cluster

We are installing an application that requires access to the ms-sql-m
protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
we are using is part of an N+1 cluster. The issue is that when we try
to communicate to the node instance xxx.xxx.123.226 recieve the
ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
an asymmetric IP communication and the response appears to be dropped
by the request as one might expect. This causing our installation to
fail.
Has anyone run into this issue before, no of a common misconfiguration
in clustering services that leads to this, or aware of any documented
bug?
Thanks in advance for you posts.Actually, this is typical of MS cluster applications. The response comes
back from the underlying NIC address, not the cluster virtual address. It
ain't a bug, it's a feature. Or at least it has always operated this way
and could therefore be considered a standard.
Sorry this isn't the answer you were looking for, but it is the way the
system actually works.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<ddnash@.gmail.com> wrote in message
news:1165524543.657106.172130@.79g2000cws.googlegroups.com...
> We are installing an application that requires access to the ms-sql-m
> protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
> we are using is part of an N+1 cluster. The issue is that when we try
> to communicate to the node instance xxx.xxx.123.226 recieve the
> ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
> an asymmetric IP communication and the response appears to be dropped
> by the request as one might expect. This causing our installation to
> fail.
> Has anyone run into this issue before, no of a common misconfiguration
> in clustering services that leads to this, or aware of any documented
> bug?
>
> Thanks in advance for you posts.
>|||I found the following article that does acknowledge the issue and
states that MS has chosen not to address it at this point, but there
are a couple of workarounds.
http://blogs.msdn.com/sql_protocols.../27/539706.aspx
Thanks for the post.
Geoff N. Hiten wrote:[vbcol=seagreen]
> Actually, this is typical of MS cluster applications. The response comes
> back from the underlying NIC address, not the cluster virtual address. It
> ain't a bug, it's a feature. Or at least it has always operated this w
ay
> and could therefore be considered a standard.
> Sorry this isn't the answer you were looking for, but it is the way the
> system actually works.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> <ddnash@.gmail.com> wrote in message
> news:1165524543.657106.172130@.79g2000cws.googlegroups.com...