A / V / Text encryption methods
D3|\||\|!$
I am looking for real-time encryption methods/protocols for streaming
A / V / Text data. I plan to build an app similar to Skype and since
Skype doesn't really reveal much about its security architecture, I'm
looking for ingenious solutions. Any suggestions/help would be
welcome.
From whatever research I did about Skype, I found the following
things:
Skype has implemented majority of its encryption modules by itself and
which are built to comply with standards but applied in their own
ingenious ways such as the AES block cipher, the RSA public-key
cryptosystem, the ISO 9796-2 signature padding scheme, the SHA-1 hash
function, and the RC4 stream cipher.
It uses 256-bit encryption in order to actively encrypt the data in
each Skype call or instant message. Skype uses 1024 bit RSA to
negotiate symmetric AES keys. User public keys are certified by the
Skype server at login using 1536 or 2048-bit RSA certificates.
The key size used for signing here is 1536-2048, which is
significantly greater than 1024-bit keys that are a global norm.
It has also set up its own CA for authentication. On first usage, a
client contacts Skype's master server which issues a certificate from
its indigenous CA.
Besides the above cryptographic algorithms, Skype has also implemented
its own proprietary key-exchange protocol which it uses for key
exchange. I guess they have borrowed most of the features of SSL and
implemented it according to their needs besides "fixing" its need for
a connection-oriented protocol.
I guess we could also have the same functionality using IPSec in
"transport" mode and creating a indigenous CA.. I DO NOT PLAN TO USE
VPNs, so using "tunnel" mode is out of question...
The question is, can we use IPSec to secure UDP data communication??
If yes, HOW?? (since using TCP to transport A / V data would cause
huge "delays".. So SSL is also out of question...)
One more option would be to use DTLS - I needed to know if NSS
supports DTLS... Have already developed apps with NSS.. so life could
be a lot more easier if NSS did support DTLS.. :D
Another option would be to use SSH but again, I'm not sure if it can
be used with UDP and also about its authentication methods. Comments
would be welcome.
Also, I'm looking for suitable forums/IRC channels to discuss the
topic more. Could the people here suggest me some???
Regards,
D3|\||\|!$
David Stutzman
-----Original Message-----
Subject: A / V / Text encryption methods
It uses 256-bit encryption in order to actively encrypt the data in
each Skype call or instant message. Skype uses 1024 bit RSA to
negotiate symmetric AES keys. User public keys are certified by the
Skype server at login using 1536 or 2048-bit RSA certificates.
The key size used for signing here is 1536-2048, which is
significantly greater than 1024-bit keys that are a global norm.
A symmetric key of 256 bits is equivalent to an RSA key of 15360 bits according to the NIST. Are they just giving a warm and fuzzy "more is better" when in reality you just attack the 1024 bit RSA keypair that's negotiating said AES key and probably becoming more and more possible each day?
Dave
Ian G
> Hi All!
>
> I am looking for real-time encryption methods/protocols for streaming
> A / V / Text data. I plan to build an app similar to Skype
Skype has a demanding set of requirements, which are unusual and
unfamiliar to people. It is basically from the p2p school of thought,
rather than the PKI school of thought you will find here.
See ref at bottom as to where to ask about this.
It probably doesn't make sense to take the demanding requirements of a
Skype replacement as equivalent to "A / V/ Text" without a bit more
thought. If you really want to do A / V streaming, then that's where
you have to look, and get a lot closer to those apps.
It's not sufficient in these apps to say "oh just use datagrams", you
have to study the nature of the stream, get into the soul of the app.
> From whatever research I did about Skype, I found the following
First mistake, ignore the numbers. Look at the protocol (which is
unknown :)
> ..... User public keys are certified by the
> Skype server at login .... RSA certificates.
It is unlikely that they are "certified", more likely they are registered.
> It has also set up its own CA for authentication. On first usage, a
> client contacts Skype's master server which issues a certificate from
> its indigenous CA.
I would be surprised if they were using certificates, there is no real
point, because the server isn't making a claim of any import.
> Besides the above cryptographic algorithms, Skype has also implemented
> its own proprietary key-exchange protocol which it uses for key
> exchange. I guess they have borrowed most of the features of SSL and
> implemented it according to their needs besides "fixing" its need for
> a connection-oriented protocol.
I doubt they used SSL at all ... the primary uses are message based, the
error handling is higher layer, and the "identity" handling is
opportunistic, to use a euphimism.
(I thought they based their design on their previous work with Kazaa.)
> The question is, can we use IPSec to secure UDP data communication??
> If yes, HOW?? (since using TCP to transport A / V data would cause
> huge "delays".. So SSL is also out of question...)
IPSec is generally an O/S level thing, or? Probably worth reading about
but research p2p designs first.
> One more option would be to use DTLS - I needed to know if NSS
> supports DTLS... Have already developed apps with NSS.. so life could
> be a lot more easier if NSS did support DTLS.. :D
IMHO, only, DTLS is a design to re-use as much of SSL technology as
possible, where this makes sense.
It is probably good to read DTLS at least, but before you do that, read
up on p2p designs.
> Another option would be to use SSH but again, I'm not sure if it can
> be used with UDP and also about its authentication methods. Comments
> would be welcome.
Standard SSH cannot be used with UDP. I have a sort of prototype that
does UDP tunnelling using SSH (it was a hobby hacking project I did to
extend some UDP payments technology), I don't recall anyone else being
so daft & dotty.
Having said that ... again, I wouldn't use this general tool for a
specific application, especially one as demanding as faux-Skype.
> Also, I'm looking for suitable forums/IRC channels to discuss the
> topic more. Could the people here suggest me some???
Architecture is possibly the most fun thing, but this forum does not
really do architecture. The best place I know for this question is the
p2p list run by zooko:
http://lists.zooko.com/mailman/listinfo/p2p-hackers
There you will find a lot of people doing similar stuff, with a fair
scattering of people who've attacked similar problems.
iang
Ben Bucksch
as Ian said, ignore Skype. Look at open-source video chat apps (there
are a few). Then look at open source crypto libs (openssl, maybe NSS,
etc.), and crypto email solutions (esp. GPG), and crypto chat solutions
(e.g. GPG in Jabber) and how the key exchange works. Then think about
how to bring the well-known open source crypto solutions and open-source
video chat apps together.
Your main problems will be:
* TCP vs. UDP, and latency
* Key exchange (compare GPG, and maybe SSH model)
Please followup to m.d.t.crypto.
Ian G
> * D3|\||\|!$
>
> -----Original Message-----
>
> It uses 256-bit encryption in order to actively encrypt the data in
> each Skype call or instant message. Skype uses 1024 bit RSA to
> negotiate symmetric AES keys. User public keys are certified by the
> Skype server at login using 1536 or 2048-bit RSA certificates.
> The key size used for signing here is 1536-2048, which is
> significantly greater than 1024-bit keys that are a global norm.
>
Yes: If you work in smart cards or other low-end hardware related
crypto, generally some attention is given to this. If you work at the
NSA, yes. They have an obsession with this, and it is reflected in
their designs. Their decisions are considered things of beauty.
No: If you work on the Internet, not really (most of the machines are
idle and bored anyway, statistically). If one works in heavily
standardised areas, one is generally stuck using whatever the document
states (e.g., recent MD5-is-to-be-dropped-rsn debate) regardless of
other logic.
The issue is a bit distracting because it reduces to numbers, and people
think this means a bigger number is better. The protocol is far more
important, and the requirements are far more important again.
> A symmetric key of 256 bits is equivalent to an RSA key of 15360 bits according to the NIST. Are they just giving a warm and fuzzy "more is better" when in reality you just attack the 1024 bit RSA keypair that's negotiating said AES key and probably becoming more and more possible each day?
Right, but the choice of 256 bits is likely more a factor of AES being
either 128 OR 256, and nothing sensible in-between. I would speculate
that they chose the larger because of Pareto-complete logic, and then
they ignore the symmetric cipher thereafter. Then, they can vary the
RSA key up and down according to their feelings of security versus
experience.
iang
Arshad Noor
While this is not a real-time encryption protocol, if you're looking
for a protocol to manage symmetric-keys across the internet, OASIS
is working on a standard called the Symmetric Key Services Markup
Language (SKSML). The current draft (DRAFT-8) of this protocol is at:
http://www.oasis-open.org/committees/document.php?document_id=30091&wg_abbrev=ekmi
It is designed to manage trillions of symmetric keys per server, and
manages keys centrally through individualized policies. An open-
source implementation of the DRAFT-1 version of the protocol is at
strongkey.org, while an OASIS-specific (DRAFT-8) implementation will
be out later this year.
If there are specific symmetric key-management requirements you have
that are not addressed in this specification, now would be a good time
to let me know.
Arshad Noor
StrongAuth, Inc.
Julien R Pierre - Sun Microsystems
Of course, when it comes to audio and video chat, part of the very data
that's being transferred can serve to authenticate the other party
(voice print, video), somewhat reducing the need for transport-level
authentication ... This doesn't prevent interception of course, but at
least you can be confident that you are communicating with the party you
intend to in real-time (even if somebody else may be snooping around).
SSL/TLS are more general and apply to protocols where very often no
other means of authentication is available.
Ben Bucksch
> Of course, when it comes to audio and video chat, part of the very
> data that's being transferred can serve to authenticate the other
> party (voice print, video), somewhat reducing the need for
> transport-level authentication ... This doesn't prevent interception
> of course
... which is the key problem.
Julien R Pierre - Sun Microsystems
Well, that's one of several problems. It doesn't do you any good if your
traffic cannot be intercepted by everyone if you are encrypting it to
the wrong person because your authentication was too weak.