Latest commit

History

45 Commits

Folders and files

NameName
Last commit message
Last commit date

Repository files navigation

Taller de Programación I - Cátedra Veiga - FIUBA

Trabajo Práctico I

Jonathan David Rosenblatt

104105

Introducción

Este es el primer trabajo práctico de la materia en el que se debe entregar un producto programado y documentado. El mismo fue programado en C y requiere conocimientos introductorios en redes y criptografía. Un objetivo de este tp es nivelar la capacidad de programación en C del alumnado, adquiriendo buenas prácticas y escribiendo buen código en el camino.

Configuración del Proyecto

Para configurar y ejecutar el código lo primero que se debe hacer es clonar el repositorio. Luego para compilar y enlazar se debe ejecutar el Makefile incluido (ejecutando make). En caso de tener errores con el compilador o el enlazador se verán escritos por stderr.

Primero se debe ejecutar el servidor:

./server <SERVER-PORT> --method=<METHOD> --key=<KEY>

Y luego el cliente:

./client <SERVER-HOST> <SERVER-PORT> --method=<METHOD> --key=<KEY>

Siendo:

  • <SERVER_HOST>: La dirección IPV4 de la persona ejecutando el servidor.
  • <SERVER-PORT>: El puerto que el servidor utilizará para comunicarse con el cliente.
  • <METHOD>: Método con el que se va a encriptar (caso cliente) y desencriptar el mensaje (caso servidor).
  • <KEY>: Llave con la que se va a encriptar y desencriptar el mensaje.

Aclaración: el mensaje que reciba el servidor tendrá sentido solo si el método y clave ingresados en ambas puntas coinciden. Pueden ingresarse valores diferentes pero la llegada muy probablemente no tenga ningún sentido.

Diseño, Redes y Cifrado

El proyecto tiene varios archivos y cada uno de ellos representa y abstrae las diferentes funcionalidades que se necesitan para que funcionen en conjunto. Las clases que terminan con "_main.c" son el esqueleto del proyecto, llaman a todas las otras funciones y verifican los outputs de todas.

Luego están las funciones client_cipherAndSend y server_decipherAndRecv que llaman y verifican lo que hacen los encriptadores, los sockets (encapsulados por los tdas client_tda y server_tda) y el lector de archivos en el caso del cliente. Estos le proveen a los _main una buena abstracción de como cada cifrador opera, de como se lee del stdin y de como operan los sockets.

Finalmente están las 3 clases encriptadoras y el socket. La implementación de los client_tda y server_tda abstraen la implementación del socket.

Todos estos archivos, además de encapsular, permiten generar código reutilizable para otros proyectos.


El software utilizado para realizar los diagramas, plantuml, interpreta los elementos ingresados como clases, pero en C no hay clases.

En el siguiente diagrama de secuencia se aprecia el flujo del programa cuando desde el servidor se quiere desencriptar lo que se recibe por red. Se ve que la capa más alta de abstracción, es decir el servidor, solamente hace algunas llamadas y no se encarga de trabajar los datos, ya que todas esas responsabilidades se las delega a las entidades de más baja abstracción.

Vemos que el servidor le pide a su TDA que se conecte con el cliente, sin saber que el mismo hace varias llamadas al socket para lograr su cometido.

Luego de establecer una conexión el servidor le delega a otra entidad el descifrado de los datos que llegan por red, y una vez más vemos como el servidor no se tiene que preocupar de como desciframos o pedimos los datos.

El server_decipherAndRecv a su vez le delega al server_tda que busque los datos y descifra todo siempre que el socket, encapsulado por el server_tda, pueda recibir datos.

Finalmente el servidor libera todos los recursos utilizados.


Desde el lado del cliente la lógica es muy parecida y casi simétrica con la del servidor. Solamente cambian las operaciones que se realizan dentro del ciclo, pero una vez más, todo está bien encapsulado y segmentado en diferentes archivos que representan las varias capas de abstracción necesarias.


Herramientas Utilizadas

Las herramientas más utilizadas en este tp fueron:

  • Valgrind: el glorioso programa que tanto nos ayuda a debuggear el código. Con flags como --track-origins=yes para ver donde se nos generan variables no inicializadas que puedan causar problemas y --track-fds=yes para ver si nos quedaron sockets sin liberar (y donde fueron creados en caso de ser necesario).

  • Gdb: el debugger de GNU, súper útil para revisar con detalle el código y encontrar más facilmente la causa de problemas como segmentation faults, loops infinitos, entre otros.

  • Tiburoncín: un software muy bueno para verificar como los datos se mandan del cliente al servidor. De especial utilidad para verificar que lo que sale del cliente llega como debería al servidor.

Conclusión

Este tp resultó ser bastante exigente y personalmente tuve que dedicarle muchas horas de trabajo.

La parte de criptografía requiere un inmenso cuidado a la hora de escribir y testear el código. Lo mismo ocurre con la parte de redes, donde uno debe sentarse a leer la extensa documentación involucrada en todas las funciones que debemos utilizar.

Como dije en la introducción y en otras partes del trabajo, se aprenden muchas cosas súper interesantes y útiles como el manejo inteligente del stack en C, criptografía básica, conocimientos de redes, prácticas desarrollando TDA's, etc.

About

No description or website provided.

Topics

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Latest commit

History

45 Commits

Folders and files

NameName
Last commit message
Last commit date

Repository files navigation

Taller de Programación I - Cátedra Veiga - FIUBA

Trabajo Práctico I

Jonathan David Rosenblatt

104105

Introducción

Este es el primer trabajo práctico de la materia en el que se debe entregar un producto programado y documentado. El mismo fue programado en C y requiere conocimientos introductorios en redes y criptografía. Un objetivo de este tp es nivelar la capacidad de programación en C del alumnado, adquiriendo buenas prácticas y escribiendo buen código en el camino.

Configuración del Proyecto

Para configurar y ejecutar el código lo primero que se debe hacer es clonar el repositorio. Luego para compilar y enlazar se debe ejecutar el Makefile incluido (ejecutando make). En caso de tener errores con el compilador o el enlazador se verán escritos por stderr.

Primero se debe ejecutar el servidor:

./server <SERVER-PORT> --method=<METHOD> --key=<KEY>

Y luego el cliente:

./client <SERVER-HOST> <SERVER-PORT> --method=<METHOD> --key=<KEY>

Siendo:

  • <SERVER_HOST>: La dirección IPV4 de la persona ejecutando el servidor.
  • <SERVER-PORT>: El puerto que el servidor utilizará para comunicarse con el cliente.
  • <METHOD>: Método con el que se va a encriptar (caso cliente) y desencriptar el mensaje (caso servidor).
  • <KEY>: Llave con la que se va a encriptar y desencriptar el mensaje.

Aclaración: el mensaje que reciba el servidor tendrá sentido solo si el método y clave ingresados en ambas puntas coinciden. Pueden ingresarse valores diferentes pero la llegada muy probablemente no tenga ningún sentido.

Diseño, Redes y Cifrado

El proyecto tiene varios archivos y cada uno de ellos representa y abstrae las diferentes funcionalidades que se necesitan para que funcionen en conjunto. Las clases que terminan con "_main.c" son el esqueleto del proyecto, llaman a todas las otras funciones y verifican los outputs de todas.

Luego están las funciones client_cipherAndSend y server_decipherAndRecv que llaman y verifican lo que hacen los encriptadores, los sockets (encapsulados por los tdas client_tda y server_tda) y el lector de archivos en el caso del cliente. Estos le proveen a los _main una buena abstracción de como cada cifrador opera, de como se lee del stdin y de como operan los sockets.

Finalmente están las 3 clases encriptadoras y el socket. La implementación de los client_tda y server_tda abstraen la implementación del socket.

Todos estos archivos, además de encapsular, permiten generar código reutilizable para otros proyectos.


El software utilizado para realizar los diagramas, plantuml, interpreta los elementos ingresados como clases, pero en C no hay clases.

En el siguiente diagrama de secuencia se aprecia el flujo del programa cuando desde el servidor se quiere desencriptar lo que se recibe por red. Se ve que la capa más alta de abstracción, es decir el servidor, solamente hace algunas llamadas y no se encarga de trabajar los datos, ya que todas esas responsabilidades se las delega a las entidades de más baja abstracción.

Vemos que el servidor le pide a su TDA que se conecte con el cliente, sin saber que el mismo hace varias llamadas al socket para lograr su cometido.

Luego de establecer una conexión el servidor le delega a otra entidad el descifrado de los datos que llegan por red, y una vez más vemos como el servidor no se tiene que preocupar de como desciframos o pedimos los datos.

El server_decipherAndRecv a su vez le delega al server_tda que busque los datos y descifra todo siempre que el socket, encapsulado por el server_tda, pueda recibir datos.

Finalmente el servidor libera todos los recursos utilizados.


Desde el lado del cliente la lógica es muy parecida y casi simétrica con la del servidor. Solamente cambian las operaciones que se realizan dentro del ciclo, pero una vez más, todo está bien encapsulado y segmentado en diferentes archivos que representan las varias capas de abstracción necesarias.


Herramientas Utilizadas

Las herramientas más utilizadas en este tp fueron:

  • Valgrind: el glorioso programa que tanto nos ayuda a debuggear el código. Con flags como --track-origins=yes para ver donde se nos generan variables no inicializadas que puedan causar problemas y --track-fds=yes para ver si nos quedaron sockets sin liberar (y donde fueron creados en caso de ser necesario).

  • Gdb: el debugger de GNU, súper útil para revisar con detalle el código y encontrar más facilmente la causa de problemas como segmentation faults, loops infinitos, entre otros.

  • Tiburoncín: un software muy bueno para verificar como los datos se mandan del cliente al servidor. De especial utilidad para verificar que lo que sale del cliente llega como debería al servidor.

Conclusión

Este tp resultó ser bastante exigente y personalmente tuve que dedicarle muchas horas de trabajo.

La parte de criptografía requiere un inmenso cuidado a la hora de escribir y testear el código. Lo mismo ocurre con la parte de redes, donde uno debe sentarse a leer la extensa documentación involucrada en todas las funciones que debemos utilizar.

Como dije en la introducción y en otras partes del trabajo, se aprenden muchas cosas súper interesantes y útiles como el manejo inteligente del stack en C, criptografía básica, conocimientos de redes, prácticas desarrollando TDA's, etc.

About

No description or website provided.

Topics

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Latest commit

History

45 Commits

Folders and files

NameName
Last commit message
Last commit date

Repository files navigation

Taller de Programación I - Cátedra Veiga - FIUBA

Trabajo Práctico I

Jonathan David Rosenblatt

104105

Introducción

Este es el primer trabajo práctico de la materia en el que se debe entregar un producto programado y documentado. El mismo fue programado en C y requiere conocimientos introductorios en redes y criptografía. Un objetivo de este tp es nivelar la capacidad de programación en C del alumnado, adquiriendo buenas prácticas y escribiendo buen código en el camino.

Configuración del Proyecto

Para configurar y ejecutar el código lo primero que se debe hacer es clonar el repositorio. Luego para compilar y enlazar se debe ejecutar el Makefile incluido (ejecutando make). En caso de tener errores con el compilador o el enlazador se verán escritos por stderr.

Primero se debe ejecutar el servidor:

./server <SERVER-PORT> --method=<METHOD> --key=<KEY>

Y luego el cliente:

./client <SERVER-HOST> <SERVER-PORT> --method=<METHOD> --key=<KEY>

Siendo:

  • <SERVER_HOST>: La dirección IPV4 de la persona ejecutando el servidor.
  • <SERVER-PORT>: El puerto que el servidor utilizará para comunicarse con el cliente.
  • <METHOD>: Método con el que se va a encriptar (caso cliente) y desencriptar el mensaje (caso servidor).
  • <KEY>: Llave con la que se va a encriptar y desencriptar el mensaje.

Aclaración: el mensaje que reciba el servidor tendrá sentido solo si el método y clave ingresados en ambas puntas coinciden. Pueden ingresarse valores diferentes pero la llegada muy probablemente no tenga ningún sentido.

Diseño, Redes y Cifrado

El proyecto tiene varios archivos y cada uno de ellos representa y abstrae las diferentes funcionalidades que se necesitan para que funcionen en conjunto. Las clases que terminan con "_main.c" son el esqueleto del proyecto, llaman a todas las otras funciones y verifican los outputs de todas.

Luego están las funciones client_cipherAndSend y server_decipherAndRecv que llaman y verifican lo que hacen los encriptadores, los sockets (encapsulados por los tdas client_tda y server_tda) y el lector de archivos en el caso del cliente. Estos le proveen a los _main una buena abstracción de como cada cifrador opera, de como se lee del stdin y de como operan los sockets.

Finalmente están las 3 clases encriptadoras y el socket. La implementación de los client_tda y server_tda abstraen la implementación del socket.

Todos estos archivos, además de encapsular, permiten generar código reutilizable para otros proyectos.


El software utilizado para realizar los diagramas, plantuml, interpreta los elementos ingresados como clases, pero en C no hay clases.

En el siguiente diagrama de secuencia se aprecia el flujo del programa cuando desde el servidor se quiere desencriptar lo que se recibe por red. Se ve que la capa más alta de abstracción, es decir el servidor, solamente hace algunas llamadas y no se encarga de trabajar los datos, ya que todas esas responsabilidades se las delega a las entidades de más baja abstracción.

Vemos que el servidor le pide a su TDA que se conecte con el cliente, sin saber que el mismo hace varias llamadas al socket para lograr su cometido.

Luego de establecer una conexión el servidor le delega a otra entidad el descifrado de los datos que llegan por red, y una vez más vemos como el servidor no se tiene que preocupar de como desciframos o pedimos los datos.

El server_decipherAndRecv a su vez le delega al server_tda que busque los datos y descifra todo siempre que el socket, encapsulado por el server_tda, pueda recibir datos.

Finalmente el servidor libera todos los recursos utilizados.


Desde el lado del cliente la lógica es muy parecida y casi simétrica con la del servidor. Solamente cambian las operaciones que se realizan dentro del ciclo, pero una vez más, todo está bien encapsulado y segmentado en diferentes archivos que representan las varias capas de abstracción necesarias.


Herramientas Utilizadas

Las herramientas más utilizadas en este tp fueron:

  • Valgrind: el glorioso programa que tanto nos ayuda a debuggear el código. Con flags como --track-origins=yes para ver donde se nos generan variables no inicializadas que puedan causar problemas y --track-fds=yes para ver si nos quedaron sockets sin liberar (y donde fueron creados en caso de ser necesario).

  • Gdb: el debugger de GNU, súper útil para revisar con detalle el código y encontrar más facilmente la causa de problemas como segmentation faults, loops infinitos, entre otros.

  • Tiburoncín: un software muy bueno para verificar como los datos se mandan del cliente al servidor. De especial utilidad para verificar que lo que sale del cliente llega como debería al servidor.

Conclusión

Este tp resultó ser bastante exigente y personalmente tuve que dedicarle muchas horas de trabajo.

La parte de criptografía requiere un inmenso cuidado a la hora de escribir y testear el código. Lo mismo ocurre con la parte de redes, donde uno debe sentarse a leer la extensa documentación involucrada en todas las funciones que debemos utilizar.

Como dije en la introducción y en otras partes del trabajo, se aprenden muchas cosas súper interesantes y útiles como el manejo inteligente del stack en C, criptografía básica, conocimientos de redes, prácticas desarrollando TDA's, etc.

About

No description or website provided.

Topics

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Latest commit

History

45 Commits

Folders and files

NameName
Last commit message
Last commit date

Repository files navigation

Taller de Programación I - Cátedra Veiga - FIUBA

Trabajo Práctico I

Jonathan David Rosenblatt

104105

Introducción

Este es el primer trabajo práctico de la materia en el que se debe entregar un producto programado y documentado. El mismo fue programado en C y requiere conocimientos introductorios en redes y criptografía. Un objetivo de este tp es nivelar la capacidad de programación en C del alumnado, adquiriendo buenas prácticas y escribiendo buen código en el camino.

Configuración del Proyecto

Para configurar y ejecutar el código lo primero que se debe hacer es clonar el repositorio. Luego para compilar y enlazar se debe ejecutar el Makefile incluido (ejecutando make). En caso de tener errores con el compilador o el enlazador se verán escritos por stderr.

Primero se debe ejecutar el servidor:

./server <SERVER-PORT> --method=<METHOD> --key=<KEY>

Y luego el cliente:

./client <SERVER-HOST> <SERVER-PORT> --method=<METHOD> --key=<KEY>

Siendo:

  • <SERVER_HOST>: La dirección IPV4 de la persona ejecutando el servidor.
  • <SERVER-PORT>: El puerto que el servidor utilizará para comunicarse con el cliente.
  • <METHOD>: Método con el que se va a encriptar (caso cliente) y desencriptar el mensaje (caso servidor).
  • <KEY>: Llave con la que se va a encriptar y desencriptar el mensaje.

Aclaración: el mensaje que reciba el servidor tendrá sentido solo si el método y clave ingresados en ambas puntas coinciden. Pueden ingresarse valores diferentes pero la llegada muy probablemente no tenga ningún sentido.

Diseño, Redes y Cifrado

El proyecto tiene varios archivos y cada uno de ellos representa y abstrae las diferentes funcionalidades que se necesitan para que funcionen en conjunto. Las clases que terminan con "_main.c" son el esqueleto del proyecto, llaman a todas las otras funciones y verifican los outputs de todas.

Luego están las funciones client_cipherAndSend y server_decipherAndRecv que llaman y verifican lo que hacen los encriptadores, los sockets (encapsulados por los tdas client_tda y server_tda) y el lector de archivos en el caso del cliente. Estos le proveen a los _main una buena abstracción de como cada cifrador opera, de como se lee del stdin y de como operan los sockets.

Finalmente están las 3 clases encriptadoras y el socket. La implementación de los client_tda y server_tda abstraen la implementación del socket.

Todos estos archivos, además de encapsular, permiten generar código reutilizable para otros proyectos.


El software utilizado para realizar los diagramas, plantuml, interpreta los elementos ingresados como clases, pero en C no hay clases.

En el siguiente diagrama de secuencia se aprecia el flujo del programa cuando desde el servidor se quiere desencriptar lo que se recibe por red. Se ve que la capa más alta de abstracción, es decir el servidor, solamente hace algunas llamadas y no se encarga de trabajar los datos, ya que todas esas responsabilidades se las delega a las entidades de más baja abstracción.

Vemos que el servidor le pide a su TDA que se conecte con el cliente, sin saber que el mismo hace varias llamadas al socket para lograr su cometido.

Luego de establecer una conexión el servidor le delega a otra entidad el descifrado de los datos que llegan por red, y una vez más vemos como el servidor no se tiene que preocupar de como desciframos o pedimos los datos.

El server_decipherAndRecv a su vez le delega al server_tda que busque los datos y descifra todo siempre que el socket, encapsulado por el server_tda, pueda recibir datos.

Finalmente el servidor libera todos los recursos utilizados.


Desde el lado del cliente la lógica es muy parecida y casi simétrica con la del servidor. Solamente cambian las operaciones que se realizan dentro del ciclo, pero una vez más, todo está bien encapsulado y segmentado en diferentes archivos que representan las varias capas de abstracción necesarias.


Herramientas Utilizadas

Las herramientas más utilizadas en este tp fueron:

  • Valgrind: el glorioso programa que tanto nos ayuda a debuggear el código. Con flags como --track-origins=yes para ver donde se nos generan variables no inicializadas que puedan causar problemas y --track-fds=yes para ver si nos quedaron sockets sin liberar (y donde fueron creados en caso de ser necesario).

  • Gdb: el debugger de GNU, súper útil para revisar con detalle el código y encontrar más facilmente la causa de problemas como segmentation faults, loops infinitos, entre otros.

  • Tiburoncín: un software muy bueno para verificar como los datos se mandan del cliente al servidor. De especial utilidad para verificar que lo que sale del cliente llega como debería al servidor.

Conclusión

Este tp resultó ser bastante exigente y personalmente tuve que dedicarle muchas horas de trabajo.

La parte de criptografía requiere un inmenso cuidado a la hora de escribir y testear el código. Lo mismo ocurre con la parte de redes, donde uno debe sentarse a leer la extensa documentación involucrada en todas las funciones que debemos utilizar.

Como dije en la introducción y en otras partes del trabajo, se aprenden muchas cosas súper interesantes y útiles como el manejo inteligente del stack en C, criptografía básica, conocimientos de redes, prácticas desarrollando TDA's, etc.

About

No description or website provided.

Topics

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Latest commit

History

45 Commits

Folders and files

NameName
Last commit message
Last commit date

Repository files navigation

Taller de Programación I - Cátedra Veiga - FIUBA

Trabajo Práctico I

Jonathan David Rosenblatt

104105

Introducción

Este es el primer trabajo práctico de la materia en el que se debe entregar un producto programado y documentado. El mismo fue programado en C y requiere conocimientos introductorios en redes y criptografía. Un objetivo de este tp es nivelar la capacidad de programación en C del alumnado, adquiriendo buenas prácticas y escribiendo buen código en el camino.

Configuración del Proyecto

Para configurar y ejecutar el código lo primero que se debe hacer es clonar el repositorio. Luego para compilar y enlazar se debe ejecutar el Makefile incluido (ejecutando make). En caso de tener errores con el compilador o el enlazador se verán escritos por stderr.

Primero se debe ejecutar el servidor:

./server <SERVER-PORT> --method=<METHOD> --key=<KEY>

Y luego el cliente:

./client <SERVER-HOST> <SERVER-PORT> --method=<METHOD> --key=<KEY>

Siendo:

  • <SERVER_HOST>: La dirección IPV4 de la persona ejecutando el servidor.
  • <SERVER-PORT>: El puerto que el servidor utilizará para comunicarse con el cliente.
  • <METHOD>: Método con el que se va a encriptar (caso cliente) y desencriptar el mensaje (caso servidor).
  • <KEY>: Llave con la que se va a encriptar y desencriptar el mensaje.

Aclaración: el mensaje que reciba el servidor tendrá sentido solo si el método y clave ingresados en ambas puntas coinciden. Pueden ingresarse valores diferentes pero la llegada muy probablemente no tenga ningún sentido.

Diseño, Redes y Cifrado

El proyecto tiene varios archivos y cada uno de ellos representa y abstrae las diferentes funcionalidades que se necesitan para que funcionen en conjunto. Las clases que terminan con "_main.c" son el esqueleto del proyecto, llaman a todas las otras funciones y verifican los outputs de todas.

Luego están las funciones client_cipherAndSend y server_decipherAndRecv que llaman y verifican lo que hacen los encriptadores, los sockets (encapsulados por los tdas client_tda y server_tda) y el lector de archivos en el caso del cliente. Estos le proveen a los _main una buena abstracción de como cada cifrador opera, de como se lee del stdin y de como operan los sockets.

Finalmente están las 3 clases encriptadoras y el socket. La implementación de los client_tda y server_tda abstraen la implementación del socket.

Todos estos archivos, además de encapsular, permiten generar código reutilizable para otros proyectos.


El software utilizado para realizar los diagramas, plantuml, interpreta los elementos ingresados como clases, pero en C no hay clases.

En el siguiente diagrama de secuencia se aprecia el flujo del programa cuando desde el servidor se quiere desencriptar lo que se recibe por red. Se ve que la capa más alta de abstracción, es decir el servidor, solamente hace algunas llamadas y no se encarga de trabajar los datos, ya que todas esas responsabilidades se las delega a las entidades de más baja abstracción.

Vemos que el servidor le pide a su TDA que se conecte con el cliente, sin saber que el mismo hace varias llamadas al socket para lograr su cometido.

Luego de establecer una conexión el servidor le delega a otra entidad el descifrado de los datos que llegan por red, y una vez más vemos como el servidor no se tiene que preocupar de como desciframos o pedimos los datos.

El server_decipherAndRecv a su vez le delega al server_tda que busque los datos y descifra todo siempre que el socket, encapsulado por el server_tda, pueda recibir datos.

Finalmente el servidor libera todos los recursos utilizados.


Desde el lado del cliente la lógica es muy parecida y casi simétrica con la del servidor. Solamente cambian las operaciones que se realizan dentro del ciclo, pero una vez más, todo está bien encapsulado y segmentado en diferentes archivos que representan las varias capas de abstracción necesarias.


Herramientas Utilizadas

Las herramientas más utilizadas en este tp fueron:

  • Valgrind: el glorioso programa que tanto nos ayuda a debuggear el código. Con flags como --track-origins=yes para ver donde se nos generan variables no inicializadas que puedan causar problemas y --track-fds=yes para ver si nos quedaron sockets sin liberar (y donde fueron creados en caso de ser necesario).

  • Gdb: el debugger de GNU, súper útil para revisar con detalle el código y encontrar más facilmente la causa de problemas como segmentation faults, loops infinitos, entre otros.

  • Tiburoncín: un software muy bueno para verificar como los datos se mandan del cliente al servidor. De especial utilidad para verificar que lo que sale del cliente llega como debería al servidor.

Conclusión

Este tp resultó ser bastante exigente y personalmente tuve que dedicarle muchas horas de trabajo.

La parte de criptografía requiere un inmenso cuidado a la hora de escribir y testear el código. Lo mismo ocurre con la parte de redes, donde uno debe sentarse a leer la extensa documentación involucrada en todas las funciones que debemos utilizar.

Como dije en la introducción y en otras partes del trabajo, se aprenden muchas cosas súper interesantes y útiles como el manejo inteligente del stack en C, criptografía básica, conocimientos de redes, prácticas desarrollando TDA's, etc.

About

No description or website provided.

Topics

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Latest commit

History

45 Commits

Folders and files

NameName
Last commit message
Last commit date

Repository files navigation

Taller de Programación I - Cátedra Veiga - FIUBA

Trabajo Práctico I

Jonathan David Rosenblatt

104105

Introducción

Este es el primer trabajo práctico de la materia en el que se debe entregar un producto programado y documentado. El mismo fue programado en C y requiere conocimientos introductorios en redes y criptografía. Un objetivo de este tp es nivelar la capacidad de programación en C del alumnado, adquiriendo buenas prácticas y escribiendo buen código en el camino.

Configuración del Proyecto

Para configurar y ejecutar el código lo primero que se debe hacer es clonar el repositorio. Luego para compilar y enlazar se debe ejecutar el Makefile incluido (ejecutando make). En caso de tener errores con el compilador o el enlazador se verán escritos por stderr.

Primero se debe ejecutar el servidor:

./server <SERVER-PORT> --method=<METHOD> --key=<KEY>

Y luego el cliente:

./client <SERVER-HOST> <SERVER-PORT> --method=<METHOD> --key=<KEY>

Siendo:

  • <SERVER_HOST>: La dirección IPV4 de la persona ejecutando el servidor.
  • <SERVER-PORT>: El puerto que el servidor utilizará para comunicarse con el cliente.
  • <METHOD>: Método con el que se va a encriptar (caso cliente) y desencriptar el mensaje (caso servidor).
  • <KEY>: Llave con la que se va a encriptar y desencriptar el mensaje.

Aclaración: el mensaje que reciba el servidor tendrá sentido solo si el método y clave ingresados en ambas puntas coinciden. Pueden ingresarse valores diferentes pero la llegada muy probablemente no tenga ningún sentido.

Diseño, Redes y Cifrado

El proyecto tiene varios archivos y cada uno de ellos representa y abstrae las diferentes funcionalidades que se necesitan para que funcionen en conjunto. Las clases que terminan con "_main.c" son el esqueleto del proyecto, llaman a todas las otras funciones y verifican los outputs de todas.

Luego están las funciones client_cipherAndSend y server_decipherAndRecv que llaman y verifican lo que hacen los encriptadores, los sockets (encapsulados por los tdas client_tda y server_tda) y el lector de archivos en el caso del cliente. Estos le proveen a los _main una buena abstracción de como cada cifrador opera, de como se lee del stdin y de como operan los sockets.

Finalmente están las 3 clases encriptadoras y el socket. La implementación de los client_tda y server_tda abstraen la implementación del socket.

Todos estos archivos, además de encapsular, permiten generar código reutilizable para otros proyectos.


El software utilizado para realizar los diagramas, plantuml, interpreta los elementos ingresados como clases, pero en C no hay clases.

En el siguiente diagrama de secuencia se aprecia el flujo del programa cuando desde el servidor se quiere desencriptar lo que se recibe por red. Se ve que la capa más alta de abstracción, es decir el servidor, solamente hace algunas llamadas y no se encarga de trabajar los datos, ya que todas esas responsabilidades se las delega a las entidades de más baja abstracción.

Vemos que el servidor le pide a su TDA que se conecte con el cliente, sin saber que el mismo hace varias llamadas al socket para lograr su cometido.

Luego de establecer una conexión el servidor le delega a otra entidad el descifrado de los datos que llegan por red, y una vez más vemos como el servidor no se tiene que preocupar de como desciframos o pedimos los datos.

El server_decipherAndRecv a su vez le delega al server_tda que busque los datos y descifra todo siempre que el socket, encapsulado por el server_tda, pueda recibir datos.

Finalmente el servidor libera todos los recursos utilizados.


Desde el lado del cliente la lógica es muy parecida y casi simétrica con la del servidor. Solamente cambian las operaciones que se realizan dentro del ciclo, pero una vez más, todo está bien encapsulado y segmentado en diferentes archivos que representan las varias capas de abstracción necesarias.


Herramientas Utilizadas

Las herramientas más utilizadas en este tp fueron:

  • Valgrind: el glorioso programa que tanto nos ayuda a debuggear el código. Con flags como --track-origins=yes para ver donde se nos generan variables no inicializadas que puedan causar problemas y --track-fds=yes para ver si nos quedaron sockets sin liberar (y donde fueron creados en caso de ser necesario).

  • Gdb: el debugger de GNU, súper útil para revisar con detalle el código y encontrar más facilmente la causa de problemas como segmentation faults, loops infinitos, entre otros.

  • Tiburoncín: un software muy bueno para verificar como los datos se mandan del cliente al servidor. De especial utilidad para verificar que lo que sale del cliente llega como debería al servidor.

Conclusión

Este tp resultó ser bastante exigente y personalmente tuve que dedicarle muchas horas de trabajo.

La parte de criptografía requiere un inmenso cuidado a la hora de escribir y testear el código. Lo mismo ocurre con la parte de redes, donde uno debe sentarse a leer la extensa documentación involucrada en todas las funciones que debemos utilizar.

Como dije en la introducción y en otras partes del trabajo, se aprenden muchas cosas súper interesantes y útiles como el manejo inteligente del stack en C, criptografía básica, conocimientos de redes, prácticas desarrollando TDA's, etc.

About

No description or website provided.

Topics

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Latest commit

History

45 Commits

Folders and files

NameName
Last commit message
Last commit date

Repository files navigation

Taller de Programación I - Cátedra Veiga - FIUBA

Trabajo Práctico I

Jonathan David Rosenblatt

104105

Introducción

Este es el primer trabajo práctico de la materia en el que se debe entregar un producto programado y documentado. El mismo fue programado en C y requiere conocimientos introductorios en redes y criptografía. Un objetivo de este tp es nivelar la capacidad de programación en C del alumnado, adquiriendo buenas prácticas y escribiendo buen código en el camino.

Configuración del Proyecto

Para configurar y ejecutar el código lo primero que se debe hacer es clonar el repositorio. Luego para compilar y enlazar se debe ejecutar el Makefile incluido (ejecutando make). En caso de tener errores con el compilador o el enlazador se verán escritos por stderr.

Primero se debe ejecutar el servidor:

./server <SERVER-PORT> --method=<METHOD> --key=<KEY>

Y luego el cliente:

./client <SERVER-HOST> <SERVER-PORT> --method=<METHOD> --key=<KEY>

Siendo:

  • <SERVER_HOST>: La dirección IPV4 de la persona ejecutando el servidor.
  • <SERVER-PORT>: El puerto que el servidor utilizará para comunicarse con el cliente.
  • <METHOD>: Método con el que se va a encriptar (caso cliente) y desencriptar el mensaje (caso servidor).
  • <KEY>: Llave con la que se va a encriptar y desencriptar el mensaje.

Aclaración: el mensaje que reciba el servidor tendrá sentido solo si el método y clave ingresados en ambas puntas coinciden. Pueden ingresarse valores diferentes pero la llegada muy probablemente no tenga ningún sentido.

Diseño, Redes y Cifrado

El proyecto tiene varios archivos y cada uno de ellos representa y abstrae las diferentes funcionalidades que se necesitan para que funcionen en conjunto. Las clases que terminan con "_main.c" son el esqueleto del proyecto, llaman a todas las otras funciones y verifican los outputs de todas.

Luego están las funciones client_cipherAndSend y server_decipherAndRecv que llaman y verifican lo que hacen los encriptadores, los sockets (encapsulados por los tdas client_tda y server_tda) y el lector de archivos en el caso del cliente. Estos le proveen a los _main una buena abstracción de como cada cifrador opera, de como se lee del stdin y de como operan los sockets.

Finalmente están las 3 clases encriptadoras y el socket. La implementación de los client_tda y server_tda abstraen la implementación del socket.

Todos estos archivos, además de encapsular, permiten generar código reutilizable para otros proyectos.


El software utilizado para realizar los diagramas, plantuml, interpreta los elementos ingresados como clases, pero en C no hay clases.

En el siguiente diagrama de secuencia se aprecia el flujo del programa cuando desde el servidor se quiere desencriptar lo que se recibe por red. Se ve que la capa más alta de abstracción, es decir el servidor, solamente hace algunas llamadas y no se encarga de trabajar los datos, ya que todas esas responsabilidades se las delega a las entidades de más baja abstracción.

Vemos que el servidor le pide a su TDA que se conecte con el cliente, sin saber que el mismo hace varias llamadas al socket para lograr su cometido.

Luego de establecer una conexión el servidor le delega a otra entidad el descifrado de los datos que llegan por red, y una vez más vemos como el servidor no se tiene que preocupar de como desciframos o pedimos los datos.

El server_decipherAndRecv a su vez le delega al server_tda que busque los datos y descifra todo siempre que el socket, encapsulado por el server_tda, pueda recibir datos.

Finalmente el servidor libera todos los recursos utilizados.


Desde el lado del cliente la lógica es muy parecida y casi simétrica con la del servidor. Solamente cambian las operaciones que se realizan dentro del ciclo, pero una vez más, todo está bien encapsulado y segmentado en diferentes archivos que representan las varias capas de abstracción necesarias.


Herramientas Utilizadas

Las herramientas más utilizadas en este tp fueron:

  • Valgrind: el glorioso programa que tanto nos ayuda a debuggear el código. Con flags como --track-origins=yes para ver donde se nos generan variables no inicializadas que puedan causar problemas y --track-fds=yes para ver si nos quedaron sockets sin liberar (y donde fueron creados en caso de ser necesario).

  • Gdb: el debugger de GNU, súper útil para revisar con detalle el código y encontrar más facilmente la causa de problemas como segmentation faults, loops infinitos, entre otros.

  • Tiburoncín: un software muy bueno para verificar como los datos se mandan del cliente al servidor. De especial utilidad para verificar que lo que sale del cliente llega como debería al servidor.

Conclusión

Este tp resultó ser bastante exigente y personalmente tuve que dedicarle muchas horas de trabajo.

La parte de criptografía requiere un inmenso cuidado a la hora de escribir y testear el código. Lo mismo ocurre con la parte de redes, donde uno debe sentarse a leer la extensa documentación involucrada en todas las funciones que debemos utilizar.

Como dije en la introducción y en otras partes del trabajo, se aprenden muchas cosas súper interesantes y útiles como el manejo inteligente del stack en C, criptografía básica, conocimientos de redes, prácticas desarrollando TDA's, etc.

About

No description or website provided.

Topics

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Latest commit

History

45 Commits

Folders and files

NameName
Last commit message
Last commit date

Repository files navigation

Taller de Programación I - Cátedra Veiga - FIUBA

Trabajo Práctico I

Jonathan David Rosenblatt

104105

Introducción

Este es el primer trabajo práctico de la materia en el que se debe entregar un producto programado y documentado. El mismo fue programado en C y requiere conocimientos introductorios en redes y criptografía. Un objetivo de este tp es nivelar la capacidad de programación en C del alumnado, adquiriendo buenas prácticas y escribiendo buen código en el camino.

Configuración del Proyecto

Para configurar y ejecutar el código lo primero que se debe hacer es clonar el repositorio. Luego para compilar y enlazar se debe ejecutar el Makefile incluido (ejecutando make). En caso de tener errores con el compilador o el enlazador se verán escritos por stderr.

Primero se debe ejecutar el servidor:

./server <SERVER-PORT> --method=<METHOD> --key=<KEY>

Y luego el cliente:

./client <SERVER-HOST> <SERVER-PORT> --method=<METHOD> --key=<KEY>

Siendo:

  • <SERVER_HOST>: La dirección IPV4 de la persona ejecutando el servidor.
  • <SERVER-PORT>: El puerto que el servidor utilizará para comunicarse con el cliente.
  • <METHOD>: Método con el que se va a encriptar (caso cliente) y desencriptar el mensaje (caso servidor).
  • <KEY>: Llave con la que se va a encriptar y desencriptar el mensaje.

Aclaración: el mensaje que reciba el servidor tendrá sentido solo si el método y clave ingresados en ambas puntas coinciden. Pueden ingresarse valores diferentes pero la llegada muy probablemente no tenga ningún sentido.

Diseño, Redes y Cifrado

El proyecto tiene varios archivos y cada uno de ellos representa y abstrae las diferentes funcionalidades que se necesitan para que funcionen en conjunto. Las clases que terminan con "_main.c" son el esqueleto del proyecto, llaman a todas las otras funciones y verifican los outputs de todas.

Luego están las funciones client_cipherAndSend y server_decipherAndRecv que llaman y verifican lo que hacen los encriptadores, los sockets (encapsulados por los tdas client_tda y server_tda) y el lector de archivos en el caso del cliente. Estos le proveen a los _main una buena abstracción de como cada cifrador opera, de como se lee del stdin y de como operan los sockets.

Finalmente están las 3 clases encriptadoras y el socket. La implementación de los client_tda y server_tda abstraen la implementación del socket.

Todos estos archivos, además de encapsular, permiten generar código reutilizable para otros proyectos.


El software utilizado para realizar los diagramas, plantuml, interpreta los elementos ingresados como clases, pero en C no hay clases.

En el siguiente diagrama de secuencia se aprecia el flujo del programa cuando desde el servidor se quiere desencriptar lo que se recibe por red. Se ve que la capa más alta de abstracción, es decir el servidor, solamente hace algunas llamadas y no se encarga de trabajar los datos, ya que todas esas responsabilidades se las delega a las entidades de más baja abstracción.

Vemos que el servidor le pide a su TDA que se conecte con el cliente, sin saber que el mismo hace varias llamadas al socket para lograr su cometido.

Luego de establecer una conexión el servidor le delega a otra entidad el descifrado de los datos que llegan por red, y una vez más vemos como el servidor no se tiene que preocupar de como desciframos o pedimos los datos.

El server_decipherAndRecv a su vez le delega al server_tda que busque los datos y descifra todo siempre que el socket, encapsulado por el server_tda, pueda recibir datos.

Finalmente el servidor libera todos los recursos utilizados.


Desde el lado del cliente la lógica es muy parecida y casi simétrica con la del servidor. Solamente cambian las operaciones que se realizan dentro del ciclo, pero una vez más, todo está bien encapsulado y segmentado en diferentes archivos que representan las varias capas de abstracción necesarias.


Herramientas Utilizadas

Las herramientas más utilizadas en este tp fueron:

  • Valgrind: el glorioso programa que tanto nos ayuda a debuggear el código. Con flags como --track-origins=yes para ver donde se nos generan variables no inicializadas que puedan causar problemas y --track-fds=yes para ver si nos quedaron sockets sin liberar (y donde fueron creados en caso de ser necesario).

  • Gdb: el debugger de GNU, súper útil para revisar con detalle el código y encontrar más facilmente la causa de problemas como segmentation faults, loops infinitos, entre otros.

  • Tiburoncín: un software muy bueno para verificar como los datos se mandan del cliente al servidor. De especial utilidad para verificar que lo que sale del cliente llega como debería al servidor.

Conclusión

Este tp resultó ser bastante exigente y personalmente tuve que dedicarle muchas horas de trabajo.

La parte de criptografía requiere un inmenso cuidado a la hora de escribir y testear el código. Lo mismo ocurre con la parte de redes, donde uno debe sentarse a leer la extensa documentación involucrada en todas las funciones que debemos utilizar.

Como dije en la introducción y en otras partes del trabajo, se aprenden muchas cosas súper interesantes y útiles como el manejo inteligente del stack en C, criptografía básica, conocimientos de redes, prácticas desarrollando TDA's, etc.

About

No description or website provided.

Topics

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages