¿Son idénticos estos comandos gpg?

Sí, estos comandos son efectivamente los mismos:

gpg -c < file > file.gpg
gpg --output file.gpg --symmetric file

Primero, -c es solo una abreviatura de --symmetric :

 -c, --symmetric             encryption only with symmetric cipher

También tenga en cuenta que los caracteres < y > se usan en Bash para I / O redirección , no forman parte de la sintaxis de opciones de GPG.

Lo que está sucediendo aquí es que GPG puede recibir información de una entrada estándar o de un archivo especificado como argumento. En lugar de dar el nombre del archivo como un argumento, < FILE solo lo alimenta a través de stdin. Cuando GPG advierte que la entrada se proporciona a través de la entrada estándar, imprimirá la salida a la salida estándar de forma predeterminada en lugar de crear un archivo (a menos que use --output ). Por lo tanto, solo puede redirigir la salida estándar con > FILE para escribir los datos cifrados en un archivo de destino.

  

el segundo comando me parece un poco más lento, ¿es por coincidencia o son diferentes estos comandos?

Pueden ser equivalentes en funcionalidad de alto nivel , pero claramente no son idénticos; los dos comandos no coinciden exactamente, por lo que no son idénticos.

No es una coincidencia que sean equivalentes en funcionalidad, ya que la decisión de gpg de usar stdin y stdout posiblemente no haya sido involuntaria.

Sin embargo, lo que es una coincidencia es que uno es más lento que el otro. Hay factores en juego aquí, como búfer de archivo , que pueden variar en la especificación y el rendimiento entre las implementaciones de la biblioteca estándar de C y mucho menos en el terminal POSIX. En pocas palabras, uno puede ser más lento en su computadora, pero a una velocidad más rápida o igual en otra configuración de hardware, usando un compilador diferente o una biblioteca estándar.

Desde un punto de vista de seguridad (que es de lo que trata este sitio), debe usar el que le resulte más cómodo. Me imagino que los diseñadores de la interfaz de usuario agregaron ambas interfaces para proporcionar una alternativa para las configuraciones de shell que no admiten canalizaciones, y eso por sí solo no representa un riesgo de seguridad significativo.