Saber, sabemos lo que son, otra cosa es que no alcancemos a conocer toda su implicación y que el único modo de resolución conocido sea la fuerza bruta.
Te interesaría conocer la definición sobre lo que son problemas NP-Completos.

En cuanto al algoritmo que expone nosoy, es subóptimo, olvídalo. Incluso el diagrama lógico es subóptimo. Sabiendo que el único primo par es dos, es ridículo aumentar en 1 el número en cada iteración.

En algún hilo se abordó algoritmos óptimos para buscarlos...

Entiendo perfectamente que personas ajenas a la seguridad, a la informática o a las matemáticas en general, diga tonterías referentes a la seguridad...

Es más díficl ya, tragar que alguien dentro de esos grupos, las suelte peregrinamente o incluso que aunque no afirme rotundamente tal o cual cosa, meta el miedo en el cuerpo a otros que no termina de comprender el problema y no les queda otra que fiarse...

No es aceptable sugerir o insinuar que un programa es inseguro meramente porque tiene antigüedad, porque es lo mismo que afirmar que solo aquello que es 'nuevo', es seguro... y eso es algo que está por demostrar, tanto como lo previo. es decir ni lo primero está demostrado (que un programa viejo sea inseguro solo por ser viejo), ni lo último está demostrado (que solo por ser nuevo es seguro), lo que deja 'en tablas', el asunto...

Tampoco es aceptable sugerir o insinuar que un 'programa desconocido', no es fiable, sin siquiera señalar a qué llama desconocido. A priori, para un usuario nuevo recién llegado al mundo de los ordenadores, absolutamente todos los programas son desconocidos, luego equivale a decir que ninguno es fiable (y quizás este fuera el mejor resumen, si tiramos del abuso de generalizar).
Todos los programas cuando se crean (por lógica) son desconocidos, luego haciendo caso de la 'sugerencia' jamás tendrían la posibilidad de ser conocidos y por tanto nos tendríamos que conformar solo con aquellos existentes en la actualizad no siendo posible crear ninguno nuevo porque 'es desconocido'.

En cambio lo de 'procedencia dudosa', es una afirmación que no arroja duda alguna al respecto.

Para terminar, mi comentario... un artículo que solo se ciñe a señalar los problemas de contraseñas y cifrado, debería aportar también las 'soluciones' para evitar cada tipo de problema que menciona, si no el artículo se queda cojo... es como emitir solo la primera mitad de un partido de fútbol (llegado a ese punto, todo el mundo espera oir, ver, leer la segunda parte). ...dicho de otro modo se queja de programas sin citar cuales, para decir que hay que usar otros conocidos, también sin citar cuales, luego al neófito, lo deja en la misma silla que estaba sentado, pero con una sensación de angustia en el cuerpo.

Esto no requiere ayuda alguna, no son un problema matemático ni de programación (per sé) es pura y simple lógica, cuentas de niño de 8 años...

Toma un papel, cuadricula un rectángulo, numera las casillas. Contínuas si usas un array unidimensional, por filas si es  bidimensional...

Marca una casilla hacia el centro como la actual...
Ahora, anota cada dirección y a su derecha las casillas que correponden a un hallazgo de por ejemplo 4 letras.
Finalmente observa la diferencia entre las casilla y analiza cual es la solución viendo que cambia.

Piensa, si no sabes pensar dedícate a otra cosa.

La solución que te ofrece Elek... digo el señor Nobody, es muy válida cuando tengas expresiones enteramente textuales, pero si el contenido procede de entresacar valores de alguna parte que vuelcas sobre un array, es preferible el método que te he descrito... también será más rápido.

Te pongo un ejemplo, tu completa, corrige allí donde precises y haz los cambios que necesites...

Primero el código de ejemplo... cuyo resultado arroja 45.
(LaClaseDondeLoPongas hace referencia a una clase donde coloques el código de la siguiente sección)

Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button3.Click
        Dim v() As String, o() As String
        Dim resultado As Single
 
        ReDim v(0 To 4), o(0 To 4)
        v(4) = "5" : v(3) = "7" : v(2) = "11" : v(1) = "13" : v(0) = "17"
        o(4) = "/" : o(3) = "-" : o(2) = "+" : o(1) = "*" : o(0) = "+"
 
        resultado = LaClaseDondeLoPongas.Operandos.Totalizar(v, o)
        System.Windows.Forms.MessageBox.Show(resultado.ToString)
    End Sub
 
 

Y el código que realiza todo el trabajo:

  Public Structure Operandos
        Public Total As Single
        Private Operando As Integer
        Private Operador As Operadores
 
        Public Enum Operadores
            OPERADOR_SUMA = 0
            OPERADOR_RESTA = 1
            OPERADOR_MULTIPLICA = 2
            OPERADOR_DIVIDE = 3
        End Enum
 
        Public Shared Function Totalizar(ByRef Valores() As String, ByRef Operadores() As String) As Single
            Dim k As UInt32
            Dim T As New Operandos
            Dim Resul As New Operandos
 
            ' NOTA: se supone que ambos arrays son igual de largos (el primer valor se considera 0, luego se entiende que el operador para el primer operando es '+').
            ' Procesa un operando de cada vez, con el operador asociado sobre el total acumulado
            '    (si entendi mal deberas corregirlo a tus necesidades) 
            For k = 0 To Valores.Length - 1
                With T
                    .Operando = Convert.ToInt32(Valores(k))
                    .Operador = ToOperador(Operadores(k))
                    .Total = Resul.Total
                    Resul = (T = Resul)
                End With
            Next
 
            Return Resul.Total
        End Function
 
        Public Shared Operator =(ByVal XY As Operandos, ByVal R As Operandos) As Operandos
            With XY
                Select Case .Operador
                    Case Operadores.OPERADOR_SUMA
                        Try
                            .Total += .Operando
                        Catch ex As Exception
                            System.Windows.Forms.MessageBox.Show(ex.Message)
                        End Try
                    Case Operadores.OPERADOR_RESTA
                        Try
                            .Total -= .Operando
                        Catch ex As Exception
                            System.Windows.Forms.MessageBox.Show(ex.Message)
                        End Try
                    Case Operadores.OPERADOR_MULTIPLICA
                        Try
                            .Total *= .Operando
                        Catch ex As Exception   ' desbordamiento, etc...
                            System.Windows.Forms.MessageBox.Show(ex.Message)
                        End Try
                    Case Operadores.OPERADOR_DIVIDE
                        Try
                            .Total /= .Operando
                        Catch ex As Exception   ' division por 0, etc...
                            System.Windows.Forms.MessageBox.Show(ex.Message)
                        End Try
                End Select
 
                Return XY
            End With
        End Operator
 
        ' Declarar un operador '=' exige declarar tambien otro '<>' (aunque no lo usemos).
        Public Shared Operator <>(ByVal XY As Operandos, ByVal R As Operandos) As Operandos
            Return Nothing
        End Operator
 
        ' Resulta autoexplicativo...
        Private Shared Function ToOperador(ByVal Op As String) As Operadores
            Select Case Op.Trim
                Case "+" : Return Operadores.OPERADOR_SUMA
                Case "-" : Return Operadores.OPERADOR_RESTA
                Case "*" : Return Operadores.OPERADOR_MULTIPLICA
                Case "/" : Return Operadores.OPERADOR_DIVIDE
            End Select
        End Function
  End Structure
 

Los operadores no son variables.
...pero, en .NET puedes sobrecargar los operadores o definir los propios.

Podrías implementar un operador 'Operar(x,y,z)', donde uno de los parámetros fuera precisamente el operador a utilizar (basado en una enumeración), los otros parámetros serían los propios del operador.
en realidad equivaldría a una función donde pasas esos parámetros y allí mediante un 'select case' evalúa la expresión con el operador elegido.

La ventaja de definir e implementar un operador es que se puede usar de la manera concreta que precises.

el qué?...

Tánto te cuesta poner una captura o por lo menos hacer una descripción clara de tu problema????

Si, utiliza básicamente arays uno actúa de stack.
Aunque se trate de grafos a menudo no es preciso ni construir una estructura de grafo ni de árbol. Son tan solo recorridos condionados según las peticiones. La función principal deriva a la otras según lo que s epida por optimización, pues no es óptimo comparar a cada instante que si se ha pedido tal o cual cosa entrar aquí o allí, se separan diferentes funciones muy similares donde cada una solo contempla en excclusiva lo que se requiere, y la comparación de lo que s epide se hace una sola vez, precisamente para derivar el trabajo a la fnción concreta.

No sabe ni necesita saber nada.
Un nodo solo tiene acceso a los que se declara a su derecha, luego basta un bucle para recorrerlos. A su vez el ítem actual (obtenido en el ciclo actual) tiene otros declarados a su derecha, luego se invoca recursivamente, y donde aquí en el bucle hace ahora las veces de hijo, en esa llamada hace las veces de padre y se recorren sus nodos hijo. Tras cada 'hijo recorrido se tiene que verificar la condición requerida, si se cumple la solución pedida se informa, dispara un evento, etc... y se continúa con otros... salvo que la solicitud fuere 'salir tras encontrar la primera solución fuere cual fuere'. Cuando un bucle no tiene más ítems a su derecha que examinar pués sale, la función recursiva retorna a la que la llamó, y avanza al siguiente 'hermano'.
En realidad es muy similar a la jerarquía del sistema de ficheros... con la salvedad de que en una jerarquía de ficheros al ser arbórea, una carpeta jamás contiene a otra que a su vez contiene a esta. en un grafo la relación de 'hijo' puede ser bidireccional sin ningún problema, por eso no interesa el nombre de 'hijo' si no que se usa preferiblemente vecino, conexión.

Las posibilidades no necesitan ser precalculadas en el sentido de cúantas hay, el algoritmo subyacente hace el recorrido pertienente, simplemente te limitas a sumar uno a cada exploración iniciada cuando se explora. Fíjate que puede haber diferentes acotaciones, por ejemplo una que impide que un nodo se visite más de una vez (para eso se usa un 'stack'), por tanto si uno ya ha sido visitado no solo lo ignora si no que al ignorarlo, también se ignoran todos los vecinos y recorridos que continúan desde él... en el ejemplo si esto no se evitará hallaría soluciones circulares y entraría en un bucle infinito, porque cuantas vueltas se le permitiría dar?, 2, 5 40, 1 millón?. La respuesta es 1.

mmm... tiene y no tiene sentido... a ver...
Se pueden hacer programas (que SI debes saber hacer), para que exploren soluciones complejas o que conlleven mucho tiempo.

El límite será siempre tu capacidad de realizar esos programas y por supuesto de esos 'problemas que no sabes'. Una cosa es no saber como lograr una solución concreta y otra muy distinta es saber que hay una solución y que se sabe como buscarla pero directamente no sabes como encontrarla.
Un ejemplo para que quede claro: el caso de los números primos... Supongamos que te piden el primo más pequeño que utiliza 60 cifras... directamente no podremos saber la solución (cual es el primo concretamente, ni tú, ni yo, ni nadie), pero al menos se necesita saber como buscar dicho primo, y en tal caso si se puede hacer ese programa que localice el primo deseado  (tarde más o menos). Si en cambio no sabes como localizar un primo cualquiera (emplázalo fuera del ejemplo por otra cosa), entonces el fracaso al hacer el programa está asegurado. Carece de sentido intentar hacer algo que no se sabe. Es como si un indio de una de esas tribus que aún siguen perdidas en el Amazonas, quisiera hacer un submarino, cuando no conocen técnicas de fabricación, ni conocen los materiales precisos para aguantar la presión del agua, orientarse, respirar, moverse, etc...

Es el enfoque correcto para usar los ordenadores y la programación es el vehículo adecuado, pero te falta quizás el conocimiento y desde luego, deja ActionScript atrás... elige un lenguaje más universal.

Vale, pero eso se llama suposición, no deja de ser un prejuicio, pero por prejuicio suele entenderse como desfavorable. La suposición en principio es buena pués te orienta un poco de por donde puedes ir, claro siempre dependerá de tu juicio... es adecuado siempre hacer una simple demostración que apunte a si puede demostrarse como falso o verdadero, si continuar con esa suposición llevará mucho tiempo y trabajo (para no perderlo tontamente, aunque a veces es necesario porque ciertas demostraciones no puedne ser satisfechas hasta que llegues a su última consecuencia).

De hehco fíjate si una suposición es buena que es bastante malo cuando no se te ocurre nada (cuando no tienes nada que suponer sobre el caso) y por tanto te encuentras vacío, sin idea, sin saber por donde tirar. La intuición, la suposición puede sacarte de ese vacío y suele valer el esfuerzo de analizarlo.

Insisto, lee... y remplaza ActionScript por otro lenguaje.

Pues tras la inversión de Elon Musk y la inmediata subida hasta por encima de los 40.000 tentado está uno... 

Wikipedia es una 'enciclopedia universal', no exactamente una enciclopedia informática. Recoge muchos artículos del tema, pero ni wikipedia ni ninguna enciclopedia conocida está enfocada a describir el asunto paso a paso como si se fuera un principante absolutamente lego en toda materia.

Por naturaleza del propio asunto, suelen describirse en términos que ya deben dominarse, sino sería inabordable.
Si al explicarte una bicicleta, en vez de decir 'pedal', cada vez tuviera que dar la explicación exahustiva de lo que es un pedal, describir la bicicleta llevaría 5.000 páginas. Ahí ya, si uno no sabe lo que es un 'pedal' puede buscar en la propia enciclopedia qué es un pedal, pero incluso así, un artículo sobre 'pedal' no tiene porqué contener la 'historia del pedal', o puede que solo se dén dos o 3 entradas históricas, ni tampoco tiene porqué venir 'cómo fabricar un pedal' ni los 500 artículos relacionados al pedal que en algún momento a alguien le pudiera interesar, pués eso requeríría un libro específico dedicado al 'pedal'... una enciclopedia solo posicionaría el 'pedal' en un contexto explicando qué es, algo sobre su origen y sus usos. Incluiso desciribiendo el pedal también se asumirá que el lector sabe lo que es 'roscado' y 'tornillo', etc...

En fin, el 'lee...' lleva puntos suspensivos, para indicar que continues, leer solo 2 artículos puede resolver las dudas que puntualmente uno tenga, o puede necesitarse leer bastante más... todo depende del nivel que se tiene   y el nivel al que se quiere llegar, cuanto mayor la diferencia tanto más lectura será conveniente.


Sobre el modo de representación, puedes hacer una abstracción y por ejemplo no necesitas para nada mantener las ridículas llaves '{} , puedes perfectamente sustituir los separadores de contenidos por otros símbolos (por ejemplo las llaves por paréntesis, que al menos en español resultan más cómodos (de teclear al menos)) a tu elección o incluso eliminarlos (como se hará a continuación y conservando aún enteramente su significado).
por ejemplo podrías hacer:
V = ABCDEF
X = AA, AB, AE, BC, BE, CD, DE, DF

Donde claramente se observa que las letras A-F remplazan la identificación de los nodos etiqeutados en la imagen con valores 1-6 y donde no resulta preciso usar las llaves, la concatenacón es suficiente para indicar una separación de elementos individuales y la coma en grupos... es más claro, simple, legible y procesable. Si los nodos además de expresar una identificación del mismo han de expresas un valor, si será preciso otro separador para diferenciar el identificador de su valor...
Nota que 'V = ABCDEF' simplemente describe que 'A-F' son nodos de un grafo llamado 'V', y que 'X = AA, AB, AE, BC, BE, CD, DE, DF' describe las relaciones entre los nodos, así el nodo 'A' (1 en la imagen) está conectado a los nodos 'A', 'B' y 'E' (1, 2 y 5 en la imagen)
También podría describirse del siguiente modo:
V = ABCDEF
A = ABE
B = ACE
C = BD
D = CEF
E = ABD
F = E

Es decir cada nodo apunta a los nodos a los que está conectado.
Mediante iteración (para recorrer los elementos de un nodo) y recursion (para recorrer los elementos de un nodo obtenido durante la iteración). Si metes cada elemento en un array podrás explorar muchas y diferentes soluciones.

Puedes considerar una expresión en la forma 'Y = CDEF' como un nodo 'Y', con 4 nodos hijos 'C','D','E' y 'F', que pueden ser explorados uno a uno en un bucle o ser accedidos de diferentes modos. Y se podrían expresar con valores, por ejemplo 'Y= C:3;D:8;E:0;F:5'.

Yo uso mucho esa disposición para ciertos problemas más o menos complejos... y como 'hablar es fácil', vaya un ejemplo como demostración...

Pongamos como ejemplo, encontrar la solución en un laberinto (tomado de la red)... observa la imagen (que pongo un poco más abajo) se compone de 10x10 cuadrículas, que he etiquetado (para una fácil y clara comprensión) en horizontales 0-9 y en verticales A-J, se marca exactamente como nodo aquella casilla que supone un cruce, un cambio de dirección, que como se puede observar tienen 2, 3 o 4 direcciones (de 4 solo hay una, G6) y también los nodos que son finales (pués pueden ser marcados como punto final).
Carece de sentido práctico anotar como nodo A1, A2, A3, pués A1 lleva a A0 y a A2, pero no cambia de sentido, cualquier ruta que pase por A1, A2, A3... lleva hacia A9 (o hacia A9 si se recorre en sentido contrario), aunque podría ser el caso de que una casilla específica fuera 'la meta' en tal caso se añade, si no, al ser solo de paso, se resume en sus límites (las que llevan a través de ellas directamente sin posibilidad de cambio). La imagen vista, es más claro que detallada con palabras (como tantas veces).


El laberinto puede verse adjunto en la imagen recién adjuntada, y marcado todos los nodos que de él resultan, es un grafo... que yo traduzco como se ve a continuación y que es fácilmente deducible (aunque ya lo he explicado antes):
Vecindad de los nodos del grafo del 'laberinto.png'
------------------------
A0= A9|H0
A9= A0|C9
B1= B2|E1
B2= B1
B3= B5|C3
B5= B3
B6= B8|C6
B8= B6
C2= D2
C3= C4|B3
C4= C3|C6|D4
C6= C4|C9|B6
C9= C6|A9|J9
D2= D3|C2
D3= D2|F3
D4= D5|C4
D5= D4|E5
D6= D7|E6
D7= D6|E7
D8= E8
E1= E2|B1
E2= E1|G2
E4= E5|F4
E5= E4|E6|D5
E6= E5|D6|G6
E7= E8|D7
E8= E7|D8
F1= G1
F3= F4|D3
F4= F3|F5|E4
F5= F4
F7= F8|G7
F8= F7|I8
G1= G2|F1
G2= G3|G1|E2
G3= G2|H3
G4= G6|I4
G6= G7|G4|E6|H6
G7= G6|F7
H0= H3|A0|J0
H3= H0|G3|I3
H5= H6|I5
H6= H7|H5|G6
H7= H6
I1= I3
I3= I4|I1|H3
I4= I3|G4
I5= H5
I6= I8
I8= I6|F8
J0= H0|J9
J9= J0|C9

El programa recibe dos llamadas.
En la primera introduce y prepara los datos, esto es esta lista se concatena mediante un separador, se envía junto a otros parámetro (por ejemplo, el separador de cada campo conceptualizado al caso).
En la segunda se explicita que se va a hacer, (el tipo de búsqueda), si se van a considerar pesos o no, y el criterio del peso o costo (por ejemplo encontrar las soluciones con el valor exacto, con el valor menor a uno dado, etc...) el nodo inicial y final. Si no se señala un nodo inicial, señala que cualquier lo puede ser. del mismo modo el nodo final puede ser un comodín indicando con ello, que cualquiera puede ser el nodo final, pero si se especifica uno, ese y solo ese será el final).

En este ejemplo solo se trata de buscar las soluciones entre un nodo 'X' y otro nodo 'Y' que uno especifique, el programa tendría que buscar las soluciones posibles... la búsqueda puede ser por fuerza bruta (no aconsejable cuando la explosión combinatoria es elevada), o acotada (por ejemplo si se establecen pesos y se busca un peso exacto, una vez superado dicho valor no es preciso seguir explorando soluciones desde el punto en que ya se ha sobrepasado dicho valor pués añadir nodos no haría si no aumentar dicho valor cuando ya sabemos desde cierto punto que ese camino ya no es válido, etc...

El ejemplo actual puede verse como el nodo inicial es A9 y el nodo final es D8, se buscan todas las soluciones posibles entre dichos nodos. Se localizan 4 y se lista la ruta de cada una...


En este ejemplo no se han especificado pesos, pueden establecerse, pués es fácil contar las casillas entre dos nodos, por ejemplo redefiniendo el nodo A0 con pesos sería: A0= A9:9|H0:7
De igual modo desde A9 a A0 habría un peso de 9 y desde H0 a A0 un peso de 7, en tal caso el peso o costo indicaría la distancia y en tal caso la búsqueda sería ligeramente distinta, pués al final devolvería (interesaría que fuera así), la de menor costo, es decir la solución que menos distancia arroje desde A9 hasta D8...
El grafo no está dirigido, esto es, se puede ir desde un nodo a cualquier otro y al revés no está restringido, cuyando un grafo está dirigido señala que solo s epuede recorrer desde un nodo a los adyacentes que estén dirigidos, por ejemplo,
imaginemos que una flcechita hubiera desde A0 a A9, A0 tendría la siguiente especificación: A0= A9|H0 , peor para A9, si no hubiera una flecha apuntando hacia A0, su especificación sería: A9= C9 en vez de A9= A0|C9


Esto es solo un ejemplo, la variedad de usos es enorme... muchos problemas que a veces uno les busca solución de cierta manera pueden igualmente ser resueltos con grafos, de hecho los lenguajes funcionales tiran mucho de esto.



Guau. Si pensar es para ti un esfuerzo, entonces tu relación con la informástica se remite a que te quedes solo como un 'usuario', no un 'desarrollador'... Lo primero solo exige utilizar (mejor o peor), lo segundo exige sí o sí, pensar.

Suena como a alguien que dice que quiere ser submarinista, pero que le da miedo cualquier masa de agua mayor que la que cabe en el lavabo de su baño.

Con 'prejuicios' no tengo claro a que te refieres resulta ambiguo.

Si pensar es para ti un problema, no podrás hacer otra cosa que 'copiar y pegar' y me temo que en ninguna parte vas a encontrar lo que exactamente tu requieras justo para copiar y pegar. Considero que te pienses seriamente qué quieres conseguir y qué estas dispuesto a hacer, si lo uno no encaja con lo otro, estás perdiendo el tiempo y me parece que sería mejor que te dedicaras a otra cosa donde esos dos puntos estén en equilibrio (igualados).

La fuerza bruta es la torpeza en forma presente.
Con alguna frecuencia me tengo que enfrentar a problemas cuya solución no es conocida, en esos caso la fuerza bruta es la última opción, cualquier heurística será siempre mucho mejor.

Descansa, si lo necesitas, pero lee... es todo un mundo maravilloso al que (al menos todos los interesados en el conocimiento), lejos de temer debieran tener por su 'amigo íntimo'.